The Glossary of Software Architecture Design

1. Foundational Concepts

Software Architecture The high-level structure of a system: its components, their responsibilities, and the relationships and communication patterns between them. Architecture decisions are the ones that are expensive to reverse later.

Architectural Style (Pattern) A named, reusable solution to organizing a system's structure — such as layered, microservices, or event-driven — that comes with well-understood trade-offs.

Component A modular, replaceable unit of a system that encapsulates a set of related responsibilities and exposes them through a well-defined interface.

Module A unit of code organized around a cohesive purpose, typically smaller in scope than a component and usually deployed as part of a larger unit rather than independently.

Coupling The degree to which one component depends on the internal details of another. Loose coupling lets components change independently; tight coupling means a change in one often forces changes in others.

Cohesion How closely related the responsibilities within a single component are. High cohesion means a component does one thing well, which tends to make it easier to understand and change.

Separation of Concerns The principle of dividing a system so that each part addresses a distinct responsibility, minimizing overlap between parts that change for different reasons.

Abstraction Hiding the implementation details of a component behind a simpler interface, so consumers depend on what it does rather than how.

Encapsulation Bundling data and the operations on that data together, while restricting direct access to the data from outside — protecting internal state from unintended changes.

Architectural Decision Record (ADR) A short document capturing a single significant architecture decision, the context that motivated it, and the trade-offs considered — used to preserve the reasoning behind decisions for future readers.

2. Architectural Styles

Monolithic Architecture A design where the entire application is built and deployed as a single, unified unit. Simple to develop and deploy early on, but can become hard to scale or change independently as it grows.

Modular Monolith A monolith that is internally organized into well-defined, loosely coupled modules with clear boundaries, aiming to keep the simplicity of a single deployable while avoiding a tangled codebase.

Microservices Architecture A style where an application is composed of small, independently deployable services, each owning a specific business capability and communicating over a network (commonly HTTP or messaging).

Service-Oriented Architecture (SOA) An earlier, broader style that structures an application as a collection of services communicating through well-defined interfaces, often via an enterprise service bus. Microservices are frequently described as a more focused, decentralized descendant of SOA.

Layered (N-Tier) Architecture A style that organizes a system into horizontal layers (e.g., presentation, business logic, data access), where each layer depends only on the layer beneath it.

Client-Server Architecture A style splitting the system into a client that requests services and a server that provides them, typically communicating over a network.

Event-Driven Architecture (EDA) A style where components communicate by producing and consuming events, rather than direct calls — decoupling producers from consumers in time and often in identity.

Hexagonal Architecture (Ports and Adapters) A style that isolates a system's core logic from external concerns (databases, UIs, third-party services) behind "ports," with "adapters" implementing those ports for specific technologies — making the core testable and technology-agnostic.

Onion Architecture A variation on hexagonal architecture that arranges the system in concentric layers, with domain logic at the center and dependencies pointing strictly inward.

Clean Architecture A style, popularized by Robert C. Martin, that generalizes hexagonal and onion ideas into a set of concentric layers with a strict rule: source code dependencies can only point inward, toward business rules, never outward toward frameworks or infrastructure.

Serverless Architecture A style where application logic runs in stateless, event-triggered functions managed by a cloud provider, which handles provisioning and scaling — removing the need to manage servers directly.

Space-Based Architecture A style designed for high scalability that removes the central database as a bottleneck by distributing both processing and in-memory data across a grid of nodes.

Peer-to-Peer (P2P) Architecture A style where nodes act as both clients and servers, sharing responsibilities and resources directly with one another rather than relying on a central server.

Pipe-and-Filter Architecture A style where data flows through a sequence of processing components ("filters") connected by channels ("pipes"), each filter transforming the data before passing it along.

3. Structural & Design Patterns

Model-View-Controller (MVC) A pattern separating an application into the Model (data and business logic), the View (presentation), and the Controller (handles input and coordinates the other two).

Model-View-ViewModel (MVVM) A variant of MVC common in UI-heavy applications, where a ViewModel exposes data and commands from the Model in a form the View can bind to directly, reducing manual UI-update code.

Repository Pattern A pattern that abstracts data access behind an interface resembling an in-memory collection, decoupling business logic from the specifics of how data is stored or retrieved.

Unit of Work A pattern that tracks changes to a set of objects during a business transaction and coordinates writing those changes out as a single atomic operation.

Domain-Driven Design (DDD) An approach to modeling complex software around the core business domain, using a shared vocabulary ("ubiquitous language") between developers and domain experts, and organizing code around concepts like entities, value objects, and aggregates.

Bounded Context A DDD concept describing an explicit boundary within which a particular domain model applies and its terms have a single, consistent meaning — different bounded contexts may model the same real-world concept differently.

Aggregate A DDD concept describing a cluster of related objects treated as a single unit for data changes, with one member designated as the "aggregate root" that controls access to the others.

Command Query Responsibility Segregation (CQRS) A pattern that separates the operations that change state (commands) from the operations that read state (queries), often using different models — or even different data stores — for each.

Event Sourcing A pattern where state changes are stored as an immutable sequence of events, rather than overwriting a current-state record. The current state is derived by replaying events, which also gives a full audit history for free.

Saga Pattern A pattern for managing data consistency across multiple services in a distributed transaction, using a sequence of local transactions with compensating actions to undo prior steps if a later step fails.

API Gateway A single entry point that sits in front of a set of backend services, routing requests and often handling cross-cutting concerns like authentication, rate limiting, and request aggregation.

Backend for Frontend (BFF) A pattern where a dedicated backend layer is built for each type of client (web, mobile, etc.), tailoring responses to that client's specific needs rather than exposing one generic API to all.

Strangler Fig Pattern An incremental migration pattern where a legacy system is gradually replaced by routing individual pieces of functionality to a new system over time, until the old system can be retired entirely.

Sidecar Pattern A pattern that deploys a helper component alongside a main service (often in the same container group), handling cross-cutting concerns like logging, monitoring, or networking without modifying the main service's code.

Circuit Breaker A pattern that detects repeated failures in calls to a dependency and temporarily "opens," failing fast on further calls, to prevent one failing component from cascading failures across the system.

Bulkhead Pattern A pattern that isolates resources (e.g., thread pools, connections) for different parts of a system, so that a failure or resource exhaustion in one area doesn't take down unrelated areas.

Anti-Corruption Layer A DDD pattern that translates between the model of a legacy or external system and the model of the current system, preventing the external model's concepts from leaking in and "corrupting" the new design.

4. Communication & Integration

Synchronous Communication A communication style where the caller waits for a response before continuing, as in a typical HTTP request/response call.

Asynchronous Communication A communication style where the caller continues without waiting for an immediate response, often via message queues or event streams, with the result delivered later.

Message Queue A component that holds messages sent from a producer until a consumer is ready to process them, decoupling the timing of production and consumption.

Publish-Subscribe (Pub/Sub) A messaging pattern where publishers send messages to a topic without knowing who (if anyone) is listening, and subscribers receive messages from topics they've subscribed to.

Message Broker Infrastructure (e.g., RabbitMQ, Kafka) that routes messages between producers and consumers, often adding durability, ordering, or delivery guarantees.

Enterprise Service Bus (ESB) A centralized middleware layer that mediates communication, routing, and transformation between services, common in traditional SOA deployments.

Remote Procedure Call (RPC) A style of inter-process communication where a program calls a procedure on a remote system as if it were a local function call, with the network communication hidden behind that abstraction.

REST (Representational State Transfer) An architectural style for networked APIs built around stateless requests, standard HTTP verbs, and resources identified by URLs.

GraphQL A query language and runtime for APIs that lets clients request exactly the data fields they need in a single request, rather than being bound to fixed endpoint responses.

gRPC A high-performance RPC framework using Protocol Buffers for serialization, commonly used for efficient service-to-service communication.

Service Mesh A dedicated infrastructure layer (e.g., Istio, Linkerd) that manages service-to-service communication — handling routing, retries, encryption, and observability — typically via sidecar proxies, without changes to application code.

Idempotency A property of an operation where performing it multiple times has the same effect as performing it once — important for safely retrying operations over unreliable networks.

5. Data Architecture

Database per Service A microservices principle where each service owns and exclusively accesses its own database, preventing services from becoming coupled through a shared schema.

Shared Database An anti-pattern (in a microservices context) where multiple services read and write to the same database, coupling them through the schema and making independent deployment risky.

Polyglot Persistence The practice of using different types of data stores (relational, document, key-value, graph, etc.) for different services or components, chosen based on each one's data access patterns.

Data Lake A centralized repository that stores large volumes of raw data in its native format, structured and unstructured alike, typically processed and organized only when it's needed for analysis.

Data Warehouse A centralized repository of structured, processed data optimized for reporting and analysis, typically populated through ETL (extract, transform, load) pipelines from operational systems.

Eventual Consistency A consistency model where, given no new updates, all replicas of a piece of data will eventually converge to the same value — trading immediate consistency for availability and partition tolerance.

Strong Consistency A consistency model guaranteeing that any read immediately reflects the most recent write, at the cost of availability or latency in a distributed system.

Sharding Splitting a dataset across multiple database instances (shards), typically by a key, to distribute load and allow horizontal scaling of data storage.

Replication Maintaining copies of the same data across multiple nodes, used to improve availability, fault tolerance, and read performance.

CAP Theorem A principle stating that a distributed data store can only guarantee two of three properties at any given time during a network partition: Consistency, Availability, and Partition tolerance.

ACID A set of properties (Atomicity, Consistency, Isolation, Durability) that guarantee reliable processing of database transactions, commonly associated with traditional relational databases.

BASE An alternative to ACID (Basically Available, Soft state, Eventually consistent) common in distributed NoSQL systems, favoring availability and scalability over strict consistency.

6. Quality Attributes (Non-Functional Requirements)

Scalability A system's ability to handle increasing load by adding resources — either vertically (bigger machines) or horizontally (more machines).

Availability The proportion of time a system is operational and able to serve requests, often expressed as a percentage ("nines") and tied to specific uptime targets.

Reliability The probability that a system performs its intended function correctly over a given period, without failure.

Resilience A system's ability to detect, absorb, and recover from failures — whether component crashes, network issues, or unexpected load — without a total outage.

Fault Tolerance A system's ability to continue operating correctly even when one or more of its components fail.

Maintainability How easily a system can be modified to fix defects, add features, or adapt to a changed environment, without introducing new problems.

Extensibility How easily new functionality can be added to a system without requiring significant changes to its existing structure.

Interoperability The ability of a system to work with, and exchange data meaningfully with, other systems — often through standardized interfaces or protocols.

Portability How easily a system, or components of it, can be moved to run in a different environment (hardware, OS, cloud provider) with minimal change.

Observability How well a system's internal state can be inferred from its external outputs — typically built from logs, metrics, and traces — enabling engineers to understand and debug production behavior.

Testability How easily a system's components can be tested in isolation, which is heavily influenced by how loosely coupled and well-abstracted the architecture is.

Security The set of architectural properties protecting a system from unauthorized access, data breaches, and malicious use, addressed through practices like authentication, authorization, and encryption designed in from the start.

7. Principles & Trade-off Concepts

SOLID Principles Five object-oriented design principles — Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion — aimed at producing understandable, flexible, and maintainable code.

Single Responsibility Principle The idea that a component should have one, and only one, reason to change.

Dependency Inversion Principle The idea that high-level modules should not depend on low-level modules directly — both should depend on abstractions, which lets implementation details be swapped without touching high-level logic.

Don't Repeat Yourself (DRY) A principle advocating that every piece of knowledge or logic should have a single, unambiguous representation within a system, to avoid the maintenance burden of duplicated logic drifting out of sync.

You Aren't Gonna Need It (YAGNI) A principle cautioning against building functionality before it's actually needed, since speculative features add complexity and are often wrong guesses about future requirements.

Conway's Law The observation that the structure of a system tends to mirror the communication structure of the organization that built it — often used as an argument for deliberately shaping team boundaries around desired architecture.

Inverse Conway Maneuver The deliberate practice of reorganizing teams to match a desired system architecture, using Conway's Law to work in an organization's favor rather than against it.

Twelve-Factor App A set of methodology principles for building software-as-a-service applications that are portable, scalable, and suited to modern cloud deployment — covering areas like config, dependencies, and stateless processes.

Technical Debt The implied cost of additional future work caused by choosing an easy or quick solution now instead of a better approach that would take longer.

Trade-off Analysis The practice of explicitly weighing competing quality attributes (e.g., consistency vs. availability, simplicity vs. flexibility) when making an architecture decision, since improving one often comes at the cost of another.

Fitness Function A concept from evolutionary architecture: an automated, objective test that verifies a system continues to meet a desired architectural characteristic (e.g., a dependency-direction rule) as it evolves.

Evolutionary Architecture An approach that treats architecture as something designed to support incremental, guided change over time, rather than a fixed blueprint decided once upfront.

*written with Claude Sonnet 5