# Architecture principles whose severity is contextual

> 191 records

This index as JSON: https://banes-lab.com/json/api/facets/architecture/severity/contextual

## Entries

- [Domain-Driven Design (DDD)](https://banes-lab.com/records/architecture/domain-driven-design.md): A convention of modeling software on the business domain's own language, split into bounded contexts with a domain model in each.
- [Domain Model](https://banes-lab.com/records/architecture/domain-model.md): A formal definition of the business concepts, rules and invariants of one context, written as types with behavior.
- [Aggregate](https://banes-lab.com/records/architecture/aggregate.md): A design pattern that groups entities under one root, which is the only entry point and keeps the group's invariants.
- [Entity](https://banes-lab.com/records/architecture/entity.md): A design pattern that models a domain object by a stable identity, which stays the same while its attributes change.
- [Domain Service](https://banes-lab.com/records/architecture/domain-service.md): A design pattern that places a domain rule spanning several entities in a stateless service named in the domain's language.
- [Runtime Discovery](https://banes-lab.com/records/architecture/runtime-discovery.md): A mechanism that finds the available handlers, plugins or services at startup by matching a naming convention, a file pattern or metadata, and registers each one it finds in place of a hand-written list.
- [Service Discovery](https://banes-lab.com/records/architecture/service-discovery.md): A mechanism that resolves a service name to a healthy network endpoint at call time through a registry.
- [Dynamic Binding](https://banes-lab.com/records/architecture/dynamic-binding.md): A mechanism that selects the implementation behind an interface at runtime, from configuration or a registry, so the choice is made at bootstrap or first use rather than fixed in code.
- [Runtime Extensibility](https://banes-lab.com/records/architecture/runtime-extensibility.md): The degree to which new capability can be added to a running system through extension points, without modifying its core.
- [Causality](https://banes-lab.com/records/architecture/causality.md): A design rule that every effect records the event that caused it, so its order can be reasoned about.
- [Causal Consistency](https://banes-lab.com/records/architecture/causal-consistency.md): A conceptual representation of a consistency guarantee in which no reader sees an effect before its cause.
- [Happens-Before Relationship](https://banes-lab.com/records/architecture/happens-before-relationship.md): A conceptual representation of the partial order in which one operation is known to precede another.
- [Event Ordering](https://banes-lab.com/records/architecture/event-ordering.md): A rule or precondition that a stateful consumer processes the events of one key in their sequence order.
- [Directed Acyclic Graph (DAG)](https://banes-lab.com/records/architecture/directed-acyclic-graph.md): A rule or precondition that every dependency points one way and the graph they form has no cycle, so its nodes can be put in topological order.
- [Vector Clocks](https://banes-lab.com/records/architecture/vector-clocks.md): A mechanism that keeps one counter per node on each update, so two updates can be compared as ordered or concurrent.
- [Lamport Clocks](https://banes-lab.com/records/architecture/lamport-clocks.md): A mechanism that stamps each event with a logical counter, advanced on every send and receive, to give a partial order.
- [Hybrid Logical Clocks](https://banes-lab.com/records/architecture/hybrid-logical-clocks.md): A mechanism that combines physical time with a logical counter, so timestamps follow causal order and stay close to wall-clock time.
- [CRDTs](https://banes-lab.com/records/architecture/crdts.md): A mechanism that stores replicated state in data types whose merge is commutative, so replicas converge without coordination.
- [Total-Order Broadcast](https://banes-lab.com/records/architecture/total-order-broadcast.md): A mechanism that delivers every message to every node in the same order, agreed by consensus.
- [CAP Theorem](https://banes-lab.com/records/architecture/cap-theorem.md): A conceptual representation of the choice a distributed store makes during a network partition, between consistency and availability.
- [PACELC Theorem](https://banes-lab.com/records/architecture/pacelc-theorem.md): A conceptual representation that extends the CAP theorem with the trade-off a healthy network still forces, between latency and consistency.
- [Control Plane](https://banes-lab.com/records/architecture/control-plane.md): Descriptive data about the desired state of a distributed runtime, held in one place and applied to every node through a management interface.
- [Orchestration](https://banes-lab.com/records/architecture/orchestration.md): A mechanism that runs a multi-step workflow from one coordinator, which calls each step in order and tracks its outcome.
- [Centralized Configuration](https://banes-lab.com/records/architecture/centralized-configuration.md): A design pattern that keeps every service's configuration in one versioned store the services read from.
- [Decentralization](https://banes-lab.com/records/architecture/decentralization.md): A design rule that decisions and runtime control sit with the teams and services that own them, joined by contracts.
- [Leader Election](https://banes-lab.com/records/architecture/leader-election.md): A mechanism that lets a group of nodes agree on one coordinator and replace it when it fails.
- [Consensus](https://banes-lab.com/records/architecture/consensus.md): A mechanism that lets a quorum of nodes commit one value, so every correct node ends up with the same value.
- [Choreography](https://banes-lab.com/records/architecture/choreography.md): A mechanism that coordinates a cross-service flow through events, with each service reacting to the previous one's event.
- [Referential Transparency](https://banes-lab.com/records/architecture/referential-transparency.md): A design rule that an expression can be replaced by its value without changing the program's behavior.
- [Formal Verification](https://banes-lab.com/records/architecture/formal-verification.md): The activity of proving, against a formal specification, that an algorithm or protocol keeps its invariants for every input.
- [Portability](https://banes-lab.com/records/architecture/portability.md): The degree to which software runs on another platform or environment without code changes.
- [Platform Independence](https://banes-lab.com/records/architecture/platform-independence.md): A design rule that portable layers reach the operating system and vendor services only through abstractions.
- [Containerization](https://banes-lab.com/records/architecture/containerization.md): A mechanism that packages an application with its runtime dependencies into an image that runs the same on any host.
- [Infrastructure as Code](https://banes-lab.com/records/architecture/infrastructure-as-code.md): The practice of declaring infrastructure in versioned files and provisioning it from them.
- [Standards Compliance](https://banes-lab.com/records/architecture/standards-compliance.md): A rule or precondition that an implementation conforms to the published standard for its protocol, format or domain.
- [Immutable Infrastructure](https://banes-lab.com/records/architecture/immutable-infrastructure.md): An approach in which servers are replaced from a new image for every change, instead of being patched in place.
- [Autonomy](https://banes-lab.com/records/architecture/autonomy.md): A design rule that a service or team owns its data and decisions, so it alone writes its data and others reach or change it only through its published API or events.
- [Event-Driven Architecture](https://banes-lab.com/records/architecture/event-driven-architecture.md): A convention of connecting services through published events, with each consumer reacting independently of the producer.
- [Publish/Subscribe Pattern](https://banes-lab.com/records/architecture/publish-subscribe-pattern.md): A design pattern in which publishers send messages to a topic and every subscriber to that topic receives them.
- [Message Queue](https://banes-lab.com/records/architecture/message-queue.md): A mechanism that holds messages durably until a consumer takes and acknowledges each one.
- [Message Broker](https://banes-lab.com/records/architecture/message-broker.md): Descriptive data about topics, queues and routing rules, held by an intermediary service that delivers messages between producers and consumers.
- [Event Bus](https://banes-lab.com/records/architecture/event-bus.md): A mechanism that dispatches each emitted event to the handlers registered for its type.
- [Event Stream](https://banes-lab.com/records/architecture/event-stream.md): A mechanism that keeps events in an ordered, replayable log that consumers read from their own offset.
- [Event Sourcing](https://banes-lab.com/records/architecture/event-sourcing.md): A design pattern that stores state as the sequence of events that produced it and rebuilds current state by replaying them.
- [CQRS](https://banes-lab.com/records/architecture/command-query-responsibility-segregation.md): A design pattern that separates the model that handles commands from the model that answers queries.
- [Asynchronous Communication](https://banes-lab.com/records/architecture/asynchronous-communication.md): A design rule that work the caller does not need at once is sent as a message, so the caller does not wait on it.
- [Eventual Consistency](https://banes-lab.com/records/architecture/eventual-consistency.md): A conceptual representation of a consistency guarantee in which replicas and projections converge once updates stop arriving.
- [Saga Pattern](https://banes-lab.com/records/architecture/saga-pattern.md): A design pattern that runs a cross-service transaction as a sequence of local steps, each paired with a compensating step.
- [Compensating Transaction](https://banes-lab.com/records/architecture/compensating-transaction.md): A mechanism that undoes the business effect of a completed step when a later step of the workflow fails.
- [Append-Only Log](https://banes-lab.com/records/architecture/append-only-log.md): A design pattern that records history as immutable entries added at the end of the log.
- [Dead-Letter Queue](https://banes-lab.com/records/architecture/dead-letter-queue.md): A design pattern that moves a message which keeps failing into a separate queue, where it can be inspected and reprocessed.
- [Idempotent Consumer](https://banes-lab.com/records/architecture/idempotent-consumer.md): A design pattern in which a consumer records each message it has processed, so a redelivered message has no second effect.
- [Competing Consumers](https://banes-lab.com/records/architecture/competing-consumers.md): A design pattern in which several consumers read from one queue, and each message goes to only one of them.
- [Fault Tolerance](https://banes-lab.com/records/architecture/fault-tolerance.md): The degree to which a system keeps operating correctly when some of its components fail.
- [Resilience](https://banes-lab.com/records/architecture/resilience.md): The degree to which a system contains failures, stays stable under stress and recovers.
- [Robustness Principle](https://banes-lab.com/records/architecture/robustness-principle.md): A design rule that a component is strict in what it sends and tolerant of harmless variation in what it receives.
- [Fallback Pattern](https://banes-lab.com/records/architecture/fallback-pattern.md): A design pattern that routes a failed call to an alternate provider or response declared in advance.
- [Retry Pattern](https://banes-lab.com/records/architecture/retry-pattern.md): A design pattern that repeats an idempotent call after a transient failure, a bounded number of times with backoff.
- [Circuit Breaker Pattern](https://banes-lab.com/records/architecture/circuit-breaker-pattern.md): A design pattern that stops calling a dependency after repeated failures and probes it again after a wait.
- [Bulkhead Pattern](https://banes-lab.com/records/architecture/bulkhead-pattern.md): A design pattern that gives each workload its own pool of threads or connections, so one workload cannot exhaust the others.
- [Backpressure](https://banes-lab.com/records/architecture/backpressure.md): A mechanism that lets a consumer signal its capacity, so a producer slows down when the consumer falls behind.
- [Gap Analysis](https://banes-lab.com/records/architecture/gap-analysis.md): The activity of comparing the current state of a system with its target state and listing each difference.
- [Evolutionary Architecture](https://banes-lab.com/records/architecture/evolutionary-architecture.md): An approach in which the architecture changes in small increments, each guarded by fitness functions.
- [Minimum Viable Architecture](https://banes-lab.com/records/architecture/minimum-viable-architecture.md): An approach in which a system starts with only the structure its current quality attributes require, and defers the rest until a force demands it.
- [Greenfield Development](https://banes-lab.com/records/architecture/greenfield-development.md): An abstraction of building a new system with no inherited code, so its boundaries are designed from the current forces.
- [Reference Architecture](https://banes-lab.com/records/architecture/reference-architecture.md): A formal definition of the modules, patterns and allowed dependencies that a family of systems instantiates.
- [Standardization](https://banes-lab.com/records/architecture/standardization.md): A design rule that one format, tool or pattern is chosen for each recurring concern and applied everywhere it occurs.
- [Self-Describing Architecture](https://banes-lab.com/records/architecture/self-describing-architecture.md): A design rule that each module declares its name, version, capabilities and requirements in metadata that tools and the runtime can read.
- [Self-Describing Structures](https://banes-lab.com/records/architecture/self-describing-structures.md): A design rule that a data structure carries its own type tags and field names, so a reader can interpret it without outside knowledge.
- [Metadata-Driven Design](https://banes-lab.com/records/architecture/metadata-driven-design.md): An approach in which behavior such as forms, routes or plugins is generated from validated metadata instead of written case by case.
- [Convention over Configuration](https://banes-lab.com/records/architecture/convention-over-configuration.md): A design rule that a framework infers settings from stable naming and placement conventions, and explicit configuration covers only the exceptions.
- [Manifest-Based Design](https://banes-lab.com/records/architecture/manifest-based-design.md): A design pattern that loads modules or plugins from a validated manifest listing each entry, version and dependency.
- [Homoiconicity](https://banes-lab.com/records/architecture/homoiconicity.md): The degree to which a language represents its programs in its own data structures, so programs can be inspected and transformed as data.
- [Code as Data](https://banes-lab.com/records/architecture/code-as-data.md): A design rule that logic to be generated or transformed is held as a typed data structure, such as a syntax tree, that tools can inspect and rewrite.
- [Metaprogramming](https://banes-lab.com/records/architecture/metaprogramming.md): A technique for writing programs that generate or transform other programs, at compile time or at runtime.
- [Reflection](https://banes-lab.com/records/architecture/reflection.md): A mechanism that lets a program read and act on type metadata about its own structure at runtime.
- [Introspection](https://banes-lab.com/records/architecture/introspection.md): A mechanism that lets a program query an object's type and public members at runtime without changing them.
- [Compile-Time Evaluation](https://banes-lab.com/records/architecture/compile-time-evaluation.md): A mechanism that computes values, checks or generated code during the build, so the work and its errors happen before runtime.
- [Domain-Specific Language (DSL)](https://banes-lab.com/records/architecture/domain-specific-language.md): A design pattern that expresses a domain's rules or workflows in a small language with a defined grammar and a validator.
- [Language-Oriented Programming](https://banes-lab.com/records/architecture/language-oriented-programming.md): An approach in which each problem domain gets its own language, with a type checker and an evaluator, and solutions are written in it.
- [Model-Driven Architecture](https://banes-lab.com/records/architecture/model-driven-architecture.md): An approach in which a formal model is the source of truth and the implementation is generated from it by transformation rules.
- [Artificial Intelligence Architecture](https://banes-lab.com/records/architecture/artificial-intelligence-architecture.md): A conceptual representation of a system that calls a model behind validated inputs, grounded context, schema-checked outputs and governance.
- [Machine Learning Architecture](https://banes-lab.com/records/architecture/machine-learning-architecture.md): A conceptual representation of a model's lifecycle as versioned data, feature, training, evaluation and serving stages.
- [Model Governance](https://banes-lab.com/records/architecture/model-governance.md): The activity of registering, evaluating and approving each model version before it is deployed.
- [Model Inference](https://banes-lab.com/records/architecture/model-inference.md): The ability to run a trained model on validated input at runtime and return a checked prediction or generation.
- [Retrieval-Augmented Generation (RAG)](https://banes-lab.com/records/architecture/retrieval-augmented-generation.md): A design pattern that retrieves relevant documents for a question and passes them to the model, so the answer can cite its sources.
- [Vector Search](https://banes-lab.com/records/architecture/vector-search.md): A mechanism that finds records whose embeddings lie close to a query's embedding.
- [Knowledge Graphs](https://banes-lab.com/records/architecture/knowledge-graphs.md): A design pattern that stores knowledge as typed entities and named relations, validated against a schema, so queries can traverse them.
- [Explainability](https://banes-lab.com/records/architecture/explainability.md): The degree to which a model's decision comes with the evidence or attribution a reviewer needs to understand it.
- [Model Safety](https://banes-lab.com/records/architecture/model-safety.md): The degree to which a model-backed system prevents harmful inputs, outputs and actions through evaluation, guardrails and monitoring.
- [Prompt Engineering](https://banes-lab.com/records/architecture/prompt-engineering.md): A technique for writing model instructions as versioned templates with fixed parameters and an evaluation for each change.
- [Model Drift Monitoring](https://banes-lab.com/records/architecture/model-drift-monitoring.md): The activity of tracking a deployed model's inputs and output quality over time and alerting when they move past a threshold.
- [Agentic Architecture](https://banes-lab.com/records/architecture/agentic-architecture.md): A design pattern in which the model chooses actions from a scoped set of tools, within a step limit and under review.
- [Observability](https://banes-lab.com/records/architecture/observability.md): The degree to which a system's internal behavior in production can be inferred from the logs, metrics and traces it emits.
- [Auditability](https://banes-lab.com/records/architecture/auditability.md): The degree to which each sensitive action can be traced afterwards to its actor, target, time and reason.
- [Audit Logging](https://banes-lab.com/records/architecture/audit-logging.md): A mechanism that appends an immutable record of each sensitive operation, naming the actor, the action, the target and the time.
- [Correlation ID](https://banes-lab.com/records/architecture/correlation-id.md): A mechanism that attaches one identifier to a request and carries it through every call, message and log line the request causes.
- [Distributed Tracing](https://banes-lab.com/records/architecture/distributed-tracing.md): A mechanism that propagates a trace context across service calls and records each call as a timed span of one trace.
- [SLO/SLI](https://banes-lab.com/records/architecture/slo-sli.md): A rule or precondition that a service's reliability is stated as a measured indicator with an objective and an error budget over a window.
- [Template Method Pattern](https://banes-lab.com/records/architecture/template-method-pattern.md): A design pattern that fixes the steps of an algorithm in a base class and lets subclasses supply the steps that vary.
- [Mediator Pattern](https://banes-lab.com/records/architecture/mediator-pattern.md): A design pattern that routes the interactions between a set of objects through one coordinating object.
- [Iterator Pattern](https://banes-lab.com/records/architecture/iterator-pattern.md): A design pattern that lets callers traverse a collection without seeing how it is stored.
- [Visitor Pattern](https://banes-lab.com/records/architecture/visitor-pattern.md): A design pattern that places each operation over a type hierarchy in its own visitor, so an operation is added without editing the element types.
- [Memento Pattern](https://banes-lab.com/records/architecture/memento-pattern.md): A design pattern in which an object captures its own state in an opaque snapshot it can later restore.
- [Null Object Pattern](https://banes-lab.com/records/architecture/null-object-pattern.md): A design pattern that represents absence with an object implementing the expected interface as a no-op.
- [Statecharts](https://banes-lab.com/records/architecture/statecharts.md): A conceptual representation of a state machine extended with nested states and parallel regions.
- [Factory Method Pattern](https://banes-lab.com/records/architecture/factory-method-pattern.md): A design pattern in which a base class calls an overridable method to create the objects its workflow uses.
- [Abstract Factory Pattern](https://banes-lab.com/records/architecture/abstract-factory-pattern.md): A design pattern that creates a whole family of related objects through one interface, so the members always match.
- [Prototype Pattern](https://banes-lab.com/records/architecture/prototype-pattern.md): A design pattern that creates new objects by cloning a prepared template and applying overrides.
- [Proxy Pattern](https://banes-lab.com/records/architecture/proxy-pattern.md): A design pattern that places a stand-in with the same interface in front of an object, to control, defer or cache access to it.
- [Bridge Pattern](https://banes-lab.com/records/architecture/bridge-pattern.md): A design pattern that separates two independent axes of variation into two hierarchies joined by composition.
- [Decorator Pattern](https://banes-lab.com/records/architecture/decorator-pattern.md): A design pattern that adds behavior to an object by wrapping it in another object with the same interface.
- [Flyweight Pattern](https://banes-lab.com/records/architecture/flyweight-pattern.md): A design pattern that shares one copy of immutable intrinsic state among many objects, each keeping only its own extrinsic state.
- [Scalability](https://banes-lab.com/records/architecture/scalability.md): The degree to which a system keeps its throughput and latency as load grows, by adding resources.
- [Horizontal Scaling](https://banes-lab.com/records/architecture/horizontal-scaling.md): A technique for adding capacity by running more stateless instances of a service behind a load balancer.
- [Vertical Scaling](https://banes-lab.com/records/architecture/vertical-scaling.md): A technique for adding capacity by giving one instance more CPU, memory or I/O.
- [Elasticity](https://banes-lab.com/records/architecture/elasticity.md): The degree to which a system's provisioned capacity follows demand up and down automatically.
- [Load Balancing](https://banes-lab.com/records/architecture/load-balancing.md): A mechanism that spreads incoming requests across healthy instances of a service.
- [Sharding](https://banes-lab.com/records/architecture/sharding.md): A design pattern that splits a dataset across separate stores by a shard key, and routes each request to the shard that holds its key.
- [Partitioning](https://banes-lab.com/records/architecture/partitioning.md): A technique for dividing data or work into independent partitions by a key, so each can be processed in parallel.
- [Caching](https://banes-lab.com/records/architecture/caching.md): A design pattern that stores the result of an expensive read or computation under a key derived from every input it depends on, and serves it again while that key matches.
- [Concurrency](https://banes-lab.com/records/architecture/concurrency.md): A conceptual representation of several tasks in progress over overlapping time, with their access to shared state coordinated.
- [Parallelism](https://banes-lab.com/records/architecture/parallelism.md): A technique for running independent units of work at the same time on several cores or workers.
- [Throughput](https://banes-lab.com/records/architecture/throughput.md): The rate at which a system completes requests, messages or items, counted per unit of time.
- [Latency](https://banes-lab.com/records/architecture/latency.md): A measure of the time between a request and its response, usually reported at percentiles.
- [Algorithmic Efficiency](https://banes-lab.com/records/architecture/algorithmic-efficiency.md): A design rule that an algorithm and its data structures are chosen for how their cost grows with input size.
- [Time Complexity](https://banes-lab.com/records/architecture/time-complexity.md): A measure of how an algorithm's running time grows as its input grows.
- [Space Complexity](https://banes-lab.com/records/architecture/space-complexity.md): A measure of how an algorithm's memory use grows as its input grows.
- [Big O Notation](https://banes-lab.com/records/architecture/big-o-notation.md): A method for classifying an algorithm by the upper bound on how its cost grows with input size, ignoring constant factors.
- [Optimization](https://banes-lab.com/records/architecture/optimization.md): The activity of changing code or configuration to reduce the cost of a bottleneck that a measurement has located.
- [Resource Utilization](https://banes-lab.com/records/architecture/resource-utilization.md): A measure of how much of the provisioned CPU, memory, I/O and network capacity is in use.
- [Rate Limiting](https://banes-lab.com/records/architecture/rate-limiting.md): A mechanism that caps how many requests a caller can make in a time window and rejects the excess.
- [Memory Efficiency](https://banes-lab.com/records/architecture/memory-efficiency.md): The degree to which a process handles its input with bounded memory, by streaming or chunking instead of loading it whole.
- [CDN / Edge Caching](https://banes-lab.com/records/architecture/cdn-edge-caching.md): A mechanism that serves cacheable content from servers near the requester, keyed by a fingerprint of the content.
- [Read Replica](https://banes-lab.com/records/architecture/read-replica.md): A technique for routing read queries to replicated copies of a database, so the primary handles only writes.
- [Queuing Theory](https://banes-lab.com/records/architecture/queuing-theory.md): A conceptual representation of a system as queues with arrival and service rates, used to predict waiting time and size capacity.
- [Streaming Architecture](https://banes-lab.com/records/architecture/streaming-architecture.md): A convention of processing data record by record as it arrives, with backpressure, instead of collecting it first.
- [Single-Pass Processing](https://banes-lab.com/records/architecture/single-pass-processing.md): A design rule that large input is read once, with every result it feeds computed in that one pass.
- [Lazy Evaluation](https://banes-lab.com/records/architecture/lazy-evaluation.md): An approach in which a value is computed only when something consumes it.
- [Sequential Access](https://banes-lab.com/records/architecture/sequential-access.md): A design pattern that reads a source in its stored order through a cursor or scan, instead of looking records up one by one.
- [Forward-Only Processing](https://banes-lab.com/records/architecture/forward-only-processing.md): A rule or precondition that a stream is read once in order, keeping only rolling state, so no decision ever needs to revisit earlier input.
- [Dataflow Architecture](https://banes-lab.com/records/architecture/dataflow-architecture.md): A convention of arranging processing as a graph of stages connected by explicit data edges, where a stage runs when its inputs arrive.
- [Windowing](https://banes-lab.com/records/architecture/windowing.md): A mechanism that groups an unbounded stream into bounded windows of event time and aggregates each window separately.
- [Fan-out/Fan-in](https://banes-lab.com/records/architecture/fan-out-fan-in.md): A design pattern that splits work into independent parts processed in parallel, then merges their results.
- [Batch-vs-Stream](https://banes-lab.com/records/architecture/batch-vs-stream.md): An approach in which the processing model, periodic batch or continuous stream, is chosen by how fresh the data must be.
- [Plugin Architecture](https://banes-lab.com/records/architecture/plugin-architecture.md): A convention of building a small core that discovers and loads plugins through declared extension points.
- [Service Registry](https://banes-lab.com/records/architecture/service-registry.md): A mechanism where services or plugins register under a key and are resolved by that key at runtime.
- [Registry Pattern](https://banes-lab.com/records/architecture/registry-pattern.md): A design pattern that replaces a conditional over kinds with a keyed table that each kind registers itself into.
- [Feature Toggle](https://banes-lab.com/records/architecture/feature-toggle.md): A mechanism that switches a code path on or off at runtime from externally held flag state, so a release can happen without a deploy.
- [Self-Healing Architecture](https://banes-lab.com/records/architecture/self-healing-architecture.md): The ability of a system to detect a failed component from its health signals and restore it without human action.
- [Health Checks](https://banes-lab.com/records/architecture/health-checks.md): A mechanism that reports whether an instance and the dependencies it needs are ready to serve, so routing and restarts can act on it.
- [Failover](https://banes-lab.com/records/architecture/failover.md): A mechanism that switches traffic or reads to a standby instance when the active one fails.
- [Redundancy](https://banes-lab.com/records/architecture/redundancy.md): A mechanism that keeps spare instances or capacity for a critical component, spread across failure domains.
- [Replication](https://banes-lab.com/records/architecture/replication.md): A mechanism that keeps copies of data on several nodes under a declared consistency policy, such as a write quorum.
- [Auto-Scaling](https://banes-lab.com/records/architecture/auto-scaling.md): The ability to change the number of running instances automatically, between set bounds, from a load metric.
- [Auto-Remediation](https://banes-lab.com/records/architecture/auto-remediation.md): The ability to run a guarded, automated response, such as a restart, a reset and replay or a compaction, when an alert or a health signal shows a failure whose fix is known.
- [Blue-Green Deployment](https://banes-lab.com/records/architecture/blue-green-deployment.md): A design pattern that deploys a release to an idle copy of production, verifies it, and switches traffic to it at once.
- [Canary Deployment](https://banes-lab.com/records/architecture/canary-deployment.md): A design pattern that sends a small share of traffic to a new release and widens the share only while its error and latency stay within limits.
- [Chaos Engineering](https://banes-lab.com/records/architecture/chaos-engineering.md): The practice of injecting controlled faults into a running system to test a stated hypothesis about how it recovers.
- [Graceful Shutdown](https://banes-lab.com/records/architecture/graceful-shutdown.md): A mechanism that, on a stop signal, stops accepting work, drains in-flight work and closes connections before the process exits.
- [RAID Redundancy](https://banes-lab.com/records/architecture/raid-redundancy.md): A technique for spreading data across several disks with mirroring or parity, so the loss of a disk loses no data.
- [Canonical Model](https://banes-lab.com/records/architecture/canonical-model.md): A design rule that a concept has one authoritative representation, and every other representation is translated to and from it.
- [Canonical Data Model](https://banes-lab.com/records/architecture/canonical-data-model.md): A design pattern in which integrated systems exchange data through one shared model, with a mapping per system.
- [Normalization](https://banes-lab.com/records/architecture/normalization.md): A technique for storing each fact once and referring to it by key wherever it is needed.
- [Zero Trust Architecture](https://banes-lab.com/records/architecture/zero-trust-architecture.md): A convention of authenticating and authorizing every request on its own identity and context, whatever network it comes from.
- [Threat Modeling](https://banes-lab.com/records/architecture/threat-modeling.md): The activity of listing a flow's assets, trust boundaries and threats, and choosing a mitigation for each threat.
- [RBAC](https://banes-lab.com/records/architecture/role-based-access-control.md): A conceptual representation of access control, Role-Based Access Control (RBAC), in which permissions attach to roles and users receive roles.
- [ABAC](https://banes-lab.com/records/architecture/attribute-based-access-control.md): A conceptual representation of access control, Attribute-Based Access Control (ABAC), in which a policy decides from attributes of the subject, the resource and the environment.
- [Encryption at Rest](https://banes-lab.com/records/architecture/encryption-at-rest.md): A mechanism that encrypts stored data with managed keys, so the storage medium alone does not reveal it.
- [Privacy by Design](https://banes-lab.com/records/architecture/privacy-by-design.md): A design rule that privacy protection is part of a system's design from its first version, covering which personal data it collects, how long it keeps it, who can see it and what its defaults expose.
- [Compliance](https://banes-lab.com/records/architecture/compliance.md): A rule or precondition that a system implements the controls a regulation or standard requires, and keeps evidence of each one.
- [Governance](https://banes-lab.com/records/architecture/governance.md): A design rule that architecture decisions are held to stated policies and standards, through review and automated gates.
- [Risk Management](https://banes-lab.com/records/architecture/risk-management.md): The activity of identifying risks, rating their likelihood and impact, and assigning each one an owner and a mitigation.
- [Continuous Compliance](https://banes-lab.com/records/architecture/continuous-compliance.md): The ability to check compliance on every change, with automated policy gates and evidence capture.
- [CSRF Protection](https://banes-lab.com/records/architecture/csrf-protection.md): A mechanism that rejects state-changing requests which lack proof of coming from the site's own pages, such as an anti-forgery token.
- [Session Management](https://banes-lab.com/records/architecture/session-management.md): A mechanism that keeps authenticated sessions on the server, with expiry, rotation and revocation, and gives the client only an opaque identifier.
- [Layered Architecture](https://banes-lab.com/records/architecture/layered-architecture.md): A convention of stacking presentation, application and persistence layers, each calling only the layer below it.
- [Microservices](https://banes-lab.com/records/architecture/microservices.md): A convention of splitting a system into services that each own their data and deploy independently.
- [Monolith Architecture](https://banes-lab.com/records/architecture/monolith-architecture.md): A convention of deploying a system as one unit, with its modules kept apart by internal boundaries.
- [Service-Oriented Architecture](https://banes-lab.com/records/architecture/service-oriented-architecture.md): A convention of exposing each business capability as a service governed by a published contract.
- [Space-Based Architecture](https://banes-lab.com/records/architecture/space-based-architecture.md): A convention of holding working state in a replicated in-memory space, so no central database limits scaling.
- [Write Barrier](https://banes-lab.com/records/architecture/write-barrier.md): A mechanism that lets a planned exclusive write to a shared surface proceed only once every peer is observed parked, beside a compare-and-swap that covers every other write.
- [Derived Party Count](https://banes-lab.com/records/architecture/derived-party-count.md): A design rule that the number of parties a body of work implies is derived from how the work is partitioned into concerns, so two parties holding one partition reach one count.
- [Fan-In Ceiling](https://banes-lab.com/records/architecture/fan-in-ceiling.md): A rule or precondition that the useful number of parties is bounded by the fan-in of the most contended surface, where claims resting on it go stale faster than they help.
- [Layer Spine Precedence](https://banes-lab.com/records/architecture/layer-spine-precedence.md): A mechanism that breaks an irreducible tie between two roles in favor of the one nearer the domain on the layer spine.
- [Case Dialect](https://banes-lab.com/records/architecture/case-dialect.md): A mechanism that binds file extensions to the case their language names files in and reads the same subject, variant and concern slots from the stem's word boundaries.
- [ACID](https://banes-lab.com/records/architecture/acid.md): A conceptual representation of the four guarantees of a database transaction: atomicity, consistency, isolation and durability.
- [Isolation](https://banes-lab.com/records/architecture/isolation.md): A rule or precondition that concurrent transactions do not see each other's uncommitted changes, to the degree the isolation level declares.
- [Optimistic Locking](https://banes-lab.com/records/architecture/optimistic-locking.md): A design pattern that checks a record's version when it is written and rejects the write if another writer changed it first, comparing only the writer's own span where a surface is fenced per writer.
- [Pessimistic Locking](https://banes-lab.com/records/architecture/pessimistic-locking.md): A design pattern that locks a record before reading it for update, so other writers wait until the transaction ends.
- [Petri Nets](https://banes-lab.com/records/architecture/petri-nets.md): A conceptual representation of concurrent flow as places holding tokens and transitions that consume and produce them, which can be analyzed for deadlock.