Glossary

Short definitions, with links to the full page where one exists. Terms are listed alphabetically.

ADR (architecture decision record)

A short document recording one significant design decision: the context, the options considered, the choice made and its consequences. ADRs explain why a system looks the way it does.

API gateway

A single entry point that sits in front of back-end services and handles routing, authentication, rate limiting and request shaping for external clients.

At-least-once delivery

A messaging guarantee that every message will be delivered, but possibly more than once. Consumers must therefore be idempotent.

Bounded context

From domain-driven design: a boundary within which a model and its terms have one consistent meaning. “Customer” may mean different things in billing and in marketing; each is its own bounded context. Often a good guide to service boundaries.

CAP theorem

States that when a network partition happens, a distributed data store must choose between consistency (every read sees the latest write) and availability (every request gets a response).

Circuit breaker

A pattern that stops calling a failing dependency for a while after repeated errors, so the failure doesn’t cascade and the dependency has time to recover.

Coupling

How much one component depends on another. Loosely coupled components can change independently; tightly coupled ones must change together.

CQRS (command query responsibility segregation)

Separating the model used to change data (commands) from the model used to read it (queries), so each can be designed and scaled for its own job.

Data mesh

A data architecture in which business domains own and publish their own data as products, instead of a central team owning one shared platform.

Domain-driven design (DDD)

An approach to software design that models the code closely on the business domain, developed together with domain experts.

Eventual consistency

A consistency model in which copies of data may briefly disagree after a change but will converge if no further changes are made.

Idempotency

The property that performing an operation more than once has the same effect as performing it once. See Idempotency.

Lakehouse

A data architecture that combines a data lake’s low-cost, open storage with a data warehouse’s tables, transactions and fast queries.

Non-functional requirements (quality attributes)

Requirements about how well a system works rather than what it does, such as performance, availability, security, scalability and maintainability.

Saga

A way to keep data consistent across services without a distributed transaction: a sequence of local transactions, each with a compensating action that undoes it if a later step fails.

Service mesh

An infrastructure layer that handles service-to-service traffic (encryption, retries, routing, telemetry) outside the application code, usually through sidecar proxies.

Strangler fig

A migration pattern that replaces a legacy system gradually by routing features one at a time to new components until the old system can be retired.

Technical debt

The future cost of choosing a quicker or easier solution now instead of a better one. Like financial debt, it accrues interest until it’s paid down.

Transactional outbox

A pattern that writes an event to an “outbox” table in the same database transaction as the business change, then publishes it separately, so the change and the event can’t get out of step.

Zero trust

A security model that grants no implicit trust based on network location. Every request is authenticated, authorized and encrypted, inside the network as well as outside.