Software Architecture Glossary

169 software architecture and system design terms in simple English, each linked to where it is taught and to the terms it connects to.

ACID: Four promises of a database transaction: Atomicity (all or nothing), Consistency (your rules hold), Isolation (concurrent transactions do not interfere, to a chosen degree) and Durability (committed data survives crashes).
Active Record: A domain object that wraps a database row and also knows how to load and save itself.
Adapter pattern: A class that translates one interface into another, so your code can use a third-party API through an interface you designed.
Aggregate: A cluster of domain objects that must stay consistent together, changed only through one entry point called the aggregate root.
Anti-corruption layer (ACL): A translation layer that converts another system’s model into yours, so its concepts and quirks do not leak into your domain.
API gateway: A single entry point in front of your services that routes requests and handles edge concerns such as authentication, rate limiting and TLS.
Append-only log: An ordered sequence of records where new records are only added at the end and existing records are never changed.
Application service: A thin coordinator for one use case: it loads aggregates, calls domain logic, saves results and publishes events, but holds no business rules itself.
Architecture characteristic: A quality the system must have beyond its features — availability, scalability, performance, security, deployability — often called an “-ility”.
Architecture decision record (ADR): A short document that records one architecture decision: its context, the options considered, the decision and its consequences.
Architecture erosion: The slow decay of a system’s structure as small shortcuts pile up, until the code no longer matches the intended architecture.
Architecture quantum: An independently deployable part of a system with high functional cohesion, including everything it needs at runtime — such as its own database — to do its job.
Architecture style: A named overall shape for a system — layered, modular monolith, microkernel, event-driven, space-based, microservices — each with typical strengths and weaknesses.
Architecture test: An automated test that checks structural rules in code — which packages may depend on which — and fails the build when a rule is broken. ArchUnit is a common Java library for this.
Authentication: Proving who a caller is — a customer, an admin or another service — for example with a password plus a second factor, or a signed token.
Authorization: Deciding what an authenticated caller is allowed to do — for example, a seller may edit their own products but not another seller’s.
Availability: The share of time a system is up and usable. 99.95% availability allows about 22 minutes of downtime in a 30-day month.
B-tree: The most common index structure in relational databases: a balanced tree of fixed-size pages, kept sorted by key and updated in place.
Backend for Frontend (BFF): A separate backend per client type — web, mobile, partner API — that shapes and combines data exactly for that client.
Blue/green deployment: Running two production environments — the current one (blue) and the new one (green) — and switching all traffic from one to the other in a single step.
Bounded context: A boundary around a part of the business where the same words mean the same thing and one model applies consistently.
Bulkhead: Isolating resources — thread pools, connection pools, instances — per dependency or feature, so one failing part cannot use up everything and sink the rest.
Cache invalidation: Removing or updating cached data when the source changes, so readers stop seeing old values.
Cache stampede: Many requests miss the cache at the same moment — often when a popular key expires — and all of them hit the database at once.
Cache-aside: The application checks the cache first; on a miss it reads the database, returns the result and stores it in the cache for next time.
Canary release: Rolling out a new version to a small slice of traffic first, watching its error rate and latency, and only then sending it to everyone.
CAP theorem: When a network partition splits a distributed system, each side must choose between staying consistent (refusing some requests) and staying available (serving possibly stale data).
Chain of Responsibility pattern: Pass a request along a line of handlers, where each one can handle it, reject it or pass it to the next.
Change data capture (CDC): Reading a database’s change log and publishing every insert, update and delete as a stream of events for other systems to consume.
Circuit breaker: A wrapper around remote calls that stops calling a dependency after too many failures, fails fast for a while, then lets a few trial calls through to check whether it has recovered.
Cohesion: How strongly the things inside one module belong together. High cohesion means code that changes for the same reason lives in the same place.
Command pattern: Turn a request into an object that holds everything needed to carry it out, so it can be queued, logged, retried or undone.
Compaction: A background process that merges storage files, keeping only the latest value for each key and dropping deleted or overwritten data.
Composite index: An index on several columns in a fixed order, such as (customer_id, created_at), most useful for queries that filter on the leading columns.
Composition over inheritance: Build behavior by combining small objects that each do one thing, rather than by extending classes into deep hierarchies.
Connascence: A way to name and grade coupling: two pieces of code are connascent if changing one forces a change in the other for the system to stay correct.
Consensus: Getting several nodes to agree on a single value — such as who the leader is or the order of writes — even when some nodes crash or messages are lost.
Consistent hashing: A way to map keys to nodes on a hash ring so that adding or removing a node moves only a small share of the keys, instead of nearly all of them.
Consumer group: A set of consumers that share the work of reading a topic: each partition is assigned to one consumer in the group, and each separate group receives every message.
Context map: A picture of the bounded contexts in a system and how they relate — who depends on whom, and how models are translated between them.
Continuous integration (CI): Merging everyone’s changes into the main branch often — at least daily — with an automated build and test run on every change.
Contract testing: Checking that a provider service still meets its consumers’ expectations by testing each side against a shared, recorded contract, instead of running both together.
Conway’s law: Systems tend to mirror the communication structure of the organization that builds them.
Core domain: The part of the business that makes the company different and where it competes; it deserves the best people and the most careful design.
Coupling: How much one part of a system depends on another. Tightly coupled parts must change, deploy or fail together; loosely coupled parts can move on their own.
CQRS (command query responsibility segregation): Using one model for changing data (commands) and separate models shaped for reading (queries).
Data Mapper: A separate layer that moves data between domain objects and database tables, so the objects know nothing about SQL.
Data Transfer Object (DTO): A simple object that carries data across a process or API boundary, with no business behavior.
Database per service: Each service owns its data store privately; other services may only reach that data through the owner’s API or events.
Dead letter queue (DLQ): A separate queue or topic where messages that keep failing (“poison messages”) are parked, so they stop blocking the messages behind them.
Decorator pattern: Wrap an object in another object with the same interface to add behavior — logging, retries, metrics — without changing the original class.
Delivery semantics: What a messaging system promises about delivery: at-most-once (may lose), at-least-once (may duplicate) or exactly-once (effects applied once, under specific conditions).
Denormalization: Storing the same data in more than one place, or precomputing it, so reads are faster — accepting extra work to keep the copies in sync.
Dependency injection (DI): Giving an object the collaborators it needs from outside — usually through its constructor — instead of letting it create or look them up itself.
Dependency inversion principle (DIP): High-level business logic should not depend on low-level details like databases or HTTP clients; both should depend on an abstraction owned by the business side.
Deployment pipeline: An automated sequence of stages — build, test, security checks, deploy to staging, deploy to production — that every change passes through on its way to users.
Design by contract: Stating what a piece of code requires (preconditions), what it guarantees (postconditions) and what always stays true (invariants) — and checking those rules in code.
Design pattern: A named, reusable solution to a design problem that keeps coming back, described with its context, the forces at play and its consequences.
Distributed monolith: A system split into services that still have to be changed and deployed together — all the costs of distribution with none of the independence.
Distributed tracing: Following one request as it passes through many services, by passing a trace id along with every call and recording a timed span for each step.
Domain event: A record that something meaningful happened in the business, named in the past tense — OrderPlaced, PaymentCaptured, StockReserved.
Domain Model: An object model of the business where data and the rules that govern it live together, such as an Order that applies discounts and refuses invalid changes itself.
Domain service: A stateless operation that expresses a business rule which does not naturally belong to any single entity or value object.
DRY (Don’t Repeat Yourself): Every piece of business knowledge should have one clear home in the system. DRY is about duplicated knowledge, not about code that merely looks similar.
Encapsulation: Hiding an object’s internal data behind methods that protect its rules, so the outside world cannot put it into an invalid state.
Entity: A domain object defined by its identity rather than its attributes: an Order is still the same order after its status and lines change.
Error budget: The amount of unreliability an SLO allows — for 99.95% over 30 days, about 22 minutes of failure. Teams spend it on risk such as releases and experiments.
Estimation: Predicting how long work will take as a range with a level of confidence, rather than a single date that sounds like a promise.
Event sourcing: Storing every change to an entity as an immutable event, and deriving its current state by replaying those events.
Event-driven architecture: A style where components communicate by publishing and reacting to events, instead of calling each other directly.
Eventual consistency: If no new writes happen, all copies of the data will eventually agree — but for a while, different readers may see different values.
Evolutionary architecture: An architecture designed to support guided, incremental change over time, with automated checks that protect the characteristics that matter.
Exactly-once processing: The effect of each message is applied exactly once, even if the message itself is delivered more than once. In practice this comes from deduplication or transactions, not from perfect delivery.
Expand/contract: Making a breaking change safely in phases: add the new form beside the old one (expand), move every user over (migrate), then remove the old form (contract).
Exponential backoff: Waiting longer after each failed retry — for example 100 ms, 200 ms, 400 ms, 800 ms — so a struggling service gets time to recover.
Facade pattern: One simple entry point in front of a complicated subsystem, so callers do not need to know its internal classes.
Factory (Factory Method & Abstract Factory): Move the decision of which concrete class to create into one place, so callers ask for “a sender for this channel” instead of calling new on a specific class.
Fail fast (crash early): When code detects that something is wrong, it should stop loudly and immediately instead of carrying on with bad data.
Failover: Switching to a standby copy when the primary fails — for a database, promoting a follower to be the new leader.
Feature flag: A runtime switch that turns a code path on or off without redeploying, so deploying code and releasing a feature become separate steps.
Fitness function: An objective, automated check that tells you whether the architecture still has a characteristic you care about — for example “checkout p95 stays under 300 ms” or “no module reads another module’s tables”.
Graceful degradation: Keeping the most important functions working, with reduced features, when part of the system fails — instead of failing completely.
Hexagonal architecture: Placing the domain at the center and connecting it to the outside world — web, database, message broker — through ports (interfaces) and adapters (implementations).
Hotspot: A partition, key or node that receives far more load than the others, so it becomes the bottleneck while the rest sit mostly idle.
Idempotency: An operation is idempotent if doing it twice has the same effect as doing it once — which makes retries and duplicate messages safe.
Index: An extra data structure that lets the database find rows by a column without scanning the whole table — faster reads in exchange for slower writes and more storage.
Information hiding: Designing a module so the decisions most likely to change are hidden behind its interface, where other modules cannot depend on them.
Interface segregation principle (ISP): Clients should not be forced to depend on methods they do not use. Prefer several small, focused interfaces over one large one.
Invariant: A business rule that must always be true, such as “an order’s total equals the sum of its lines” or “stock never goes below zero”.
Isolation level: A setting that decides how much concurrent transactions can see of each other’s work — and so which anomalies, such as dirty reads or lost updates, can happen — trading safety for performance.
Jitter: Adding randomness to retry delays or expiry times so that many clients do not all act at the same instant.
Kafka partition: A Kafka topic is split into partitions, each an ordered, append-only log. Ordering is guaranteed within a partition, not across the whole topic.
Last responsible moment: Delaying an important decision until just before not deciding would start to cost you, so you decide with as much information as possible.
Layered architecture: Organizing code into horizontal layers — presentation, business/domain, persistence — where each layer only calls the layer below it.
Linearizability: A strong consistency guarantee: the system behaves as if there were a single copy of the data, and once a write completes, every later read sees it.
Liskov substitution principle (LSP): A subtype must be usable anywhere its parent type is expected without surprising the caller — it must keep the parent’s promises.
Load balancer: A component that spreads incoming requests across several instances of a service, and stops sending traffic to instances that fail health checks.
Lost update: Two transactions read the same value, both change it, and the second write silently overwrites the first — one change disappears.
LSM-tree: A storage design that buffers writes in memory, flushes them to disk as sorted, immutable files, and merges those files in the background.
Microkernel architecture: A small core system plus plug-in modules that add features, so new capabilities arrive as plug-ins without changing the core.
Microservices: An architecture of small services, each modeled around a business capability, owning its own data and deployable on its own.
Modular monolith: A single deployable application split into modules with strict boundaries — each owning its data and exposing a small API — so it is organized like services but runs as one process.
Monolith: A system deployed as a single unit, where all features run in one process and usually share one database.
Monotonic reads: A guarantee that once you have seen some data, later reads will not show you an older version — time does not appear to go backwards.
MVCC (multi-version concurrency control): The database keeps several versions of a row, so readers see a consistent snapshot while writers create new versions — and readers and writers do not block each other.
N+1 query problem: Loading a list with one query, then running one more query per item to fetch related data — 1 + N round trips where one or two would do.
Observability: How well you can understand what a running system is doing — and why — from the data it emits: logs, metrics and traces.
Observer pattern: Let an object announce “something happened” to any number of listeners, without knowing who they are or what they do.
Offset: A record’s position number within a Kafka partition. Consumers track the offset they have processed up to, so they can resume after a restart.
Open/closed principle (OCP): Code should be open for extension but closed for modification: you add new behavior by adding new code, not by editing code that already works.
Optimistic locking: Let concurrent edits proceed without locks, then detect a conflict at save time — usually with a version number — and reject the late writer.
Orchestration vs choreography: Two ways to coordinate a workflow across services: a central orchestrator tells each service what to do, or services react to each other’s events with no central controller.
Orthogonality: Two parts of a system are orthogonal when changing one does not affect the other. In an orthogonal design, one change breaks at most one thing.
Partial failure: In a distributed system some parts can fail while others keep working — and you often cannot tell whether a remote call failed, is just slow, or succeeded but the reply was lost.
Partitioning: Splitting a large dataset across several machines so each one stores and serves only part of the data.
Percentile latency (p95, p99): The response time that a given share of requests beat. A p95 of 1.2 s means 95% of requests finished within 1.2 s and 5% took longer.
Pessimistic locking: Lock data before changing it so nobody else can modify it until you are done — for example with SELECT ... FOR UPDATE.
Phantom: When another transaction inserts or deletes rows that match a query’s search condition, so running the same query again would give a different set of rows.
Polymorphism: Calling the same method on different objects and getting behavior that fits each one — the caller does not need to know which concrete type it holds.
Quorum: The minimum number of nodes that must acknowledge a read or write for it to count — often a majority.
Rate limiting: Capping how many requests a client can make in a time window, to protect a service from overload and abuse.
Read-your-writes consistency: A guarantee that after you save something, your own later reads will show it — even if other users may briefly still see the old value.
Rebalancing: Moving data between nodes when nodes are added or removed, or when load becomes uneven, so each node carries a fair share.
Refactoring: Changing the internal structure of code without changing what it does, in small steps, with tests proving the behavior stayed the same.
Replication: Keeping copies of the same data on several machines, for fault tolerance, more read capacity and lower latency for users far away.
Replication lag: The delay between a write on the leader and that write appearing on a follower. With asynchronous replication it is usually small, but it can grow to seconds or minutes under load.
Repository: A collection-like interface for getting and storing domain objects — orders.findById(id), orders.save(order) — that hides how and where they are stored.
Retry storm: When failures trigger retries that multiply traffic, overloading an already struggling service and turning a slowdown into a cascading outage.
Reversibility: Designing so that big decisions — the database, the cloud vendor, the payment gateway — can be changed later without rewriting everything.
RPO and RTO: Two disaster-recovery targets. RPO (recovery point objective) is how much recent data you can afford to lose; RTO (recovery time objective) is how long you can afford to be down.
Saga: A long business transaction split into a sequence of local transactions, where a failure triggers compensating actions that undo the earlier steps.
Scalability: The ability of a system to handle more load — users, orders, data — by adding resources, without its performance falling apart.
Selectivity: How much a condition narrows down the rows. A highly selective condition matches few rows (one order id); a poorly selective one matches many (status is DELIVERED).
Separation of concerns: Keeping different kinds of work — HTTP handling, business rules, persistence, notifications — in different parts of the code, so each can be understood and changed on its own.
Serializability: The strongest isolation guarantee: concurrent transactions produce the same result as if they had run one after another in some order.
Service discovery: How a service finds the current network addresses of the services it calls, when instances start, stop and move all the time.
Service Layer: A layer that defines the application’s use cases — placeOrder, issueRefund — and coordinates transactions, security and calls into the domain for each one.
Service mesh: An infrastructure layer, usually proxies running beside each service instance, that handles service-to-service traffic: mutual TLS, retries, timeouts, routing and telemetry.
Shared kernel: A small part of a model that two bounded contexts agree to share and change only together.
Single responsibility principle (SRP): A class or module should have one reason to change — it should answer to one group of people with one kind of change.
SLI (service level indicator): A measured number that shows how well a service is doing from the user’s point of view, such as the share of checkout requests that succeed within 300 ms.
SLO (service level objective): A target for an SLI over a time window, such as “99.95% of checkout requests succeed over each 30 days”. It defines how reliable is reliable enough.
Snapshot isolation: Each transaction reads from a consistent snapshot of the database taken when it started, so it never sees changes other transactions make in the meantime.
SOLID principles: Five object-oriented design principles — Single responsibility, Open/closed, Liskov substitution, Interface segregation and Dependency inversion — that help classes stay easy to change.
SSTable: A Sorted String Table: an immutable file of key-value pairs sorted by key, the on-disk building block of LSM-trees.
State pattern: Represent each state of an object as its own class that knows which actions and transitions are allowed, instead of one big switch on a status field.
Strangler fig: Replacing a legacy system piece by piece: put a routing layer in front, move one capability at a time to the new system, and retire the old parts as they empty out.
Strategy pattern: Put each interchangeable way of doing one job in its own class behind a shared interface, and let the caller choose which one to use.
Stream processing: Processing events continuously as they arrive, instead of collecting them and processing a large batch later.
Technical debt: The future cost of shortcuts in code or design. Like a loan, it lets you move faster now, but you pay interest every time you work around it.
Tell, don’t ask: Tell an object what to do instead of asking for its data and deciding yourself, so behavior stays next to the data it protects. Its cousin, the Law of Demeter, warns against reaching through chains of objects.
Template Method pattern: A base class fixes the steps of an algorithm and lets subclasses fill in the steps that vary.
Temporal coupling: When one service can only work if another service is up and responding at the same moment — typical of synchronous request/response calls.
Test pyramid: A guide for balancing tests: many fast unit tests at the bottom, fewer integration tests in the middle, and a small number of slow end-to-end tests at the top.
Test-driven development (TDD): Writing a failing test first, then just enough code to make it pass, then cleaning up — in short “red, green, refactor” cycles.
Threat modeling: A structured way to ask “what could go wrong?” for a design: list what is valuable, where attackers can get in, and how you will defend each entry point.
Timeout: A limit on how long you will wait for a remote call before giving up. Without one, a slow dependency can tie up all your threads.
Tracer bullet: A thin but real slice of the system that goes end to end through every layer, built first and kept. It proves the architecture works before you fill in the features.
Trade-off analysis: Comparing design options by what each one improves and what it makes worse, against the characteristics that matter most for this system.
Transaction Script: Organizing business logic as one procedure per request or use case, which reads data, applies the rules and writes the results.
Transactional outbox: Write an event into an outbox table in the same database transaction as the business change, then publish it to the broker separately — so the change and the event are saved together or not at all.
Two-phase commit (2PC): A protocol that makes several databases commit a transaction together: a coordinator asks every participant to prepare, and only if all say yes does it tell them to commit.
Ubiquitous language: A shared vocabulary that developers and business experts use in conversation, documents and code — within one bounded context.
Unit of Work: An object that tracks every change made during a business transaction and writes them all to the database together at the end.
Value object: An immutable object defined only by its values, with no identity of its own — Money(499, INR) equals any other Money(499, INR).
Write amplification: When one logical write causes several physical writes to disk — to the log, to data pages, to indexes and again during compaction.
Write skew: Two transactions read the same data, each decides it is safe to act, and each writes a different row — together they break a rule that neither broke alone.
Write-ahead log (WAL): An append-only file where a database records each change before applying it to the data files, so it can recover after a crash.
Zero trust: A security model where nothing is trusted just because it is inside the network; every request is authenticated and authorized, including service-to-service calls.