Architecture has a language of its own. This glossary defines the terms you'll encounter throughout this collection — and in real architectural conversations.
Don't try to memorize it. Use it as a reference. Come back to it whenever a term feels fuzzy.
A
Availability
The percentage of time a system is operational and accessible. Usually expressed as "nines" — 99.9% means ~8.7 hours of downtime per year, 99.99% means ~52 minutes. High availability requires redundancy and failover mechanisms.
API (Application Programming Interface)
A contract between two systems defining how they communicate — what requests are valid, what responses look like, and what errors to expect. The shape of an API is an architectural decision.
API Gateway
A single entry point for client requests that routes them to the appropriate backend service. Handles cross-cutting concerns like authentication, rate limiting, and logging.
C
CAP Theorem
A distributed systems principle: a system can only guarantee two of three properties simultaneously — Consistency (every read gets the latest write), Availability (every request gets a response), Partition tolerance (the system works despite network failures). In practice, partition tolerance is mandatory, so the real trade-off is between consistency and availability.
Caching
Storing the result of an expensive operation (database query, computation, API call) so it can be served faster next time. Introduces complexity around cache invalidation — one of the hardest problems in engineering.
CQRS (Command Query Responsibility Segregation)
Separating the model used to read data (queries) from the model used to write data (commands). Enables independent scaling and optimization of reads and writes.
Consistency
All nodes in a distributed system see the same data at the same time. Strong consistency is expensive; eventual consistency is a common trade-off.
D
Distributed System
A system where components run on multiple machines and communicate over a network. Introduces challenges around consistency, latency, partial failure, and coordination that don't exist in single-machine systems.
DNS (Domain Name System)
The system that translates human-readable domain names (e.g.
example.com) into IP addresses. An often-overlooked but critical part of system design.E
Event-Driven Architecture (EDA)
A style where components communicate by producing and consuming events, rather than calling each other directly. Decouples producers from consumers and enables high scalability, at the cost of increased complexity in tracing and debugging.
Event Sourcing
Instead of storing just the current state, you store the full sequence of events that led to it. The current state is derived by replaying events. Enables auditability and temporal queries.
F
Fault Tolerance
The ability of a system to continue operating correctly even when some components fail. Achieved through redundancy, replication, and graceful degradation.
Functional Requirements
What a system does — the features and behaviors visible to users. Contrast with non-functional requirements.
H
Horizontal Scaling (Scale Out)
Adding more machines to handle increased load. Generally preferred for distributed systems. Contrast with vertical scaling.
High Availability (HA)
Designing a system to minimize downtime, typically through redundancy, load balancing, and automated failover.
L
Latency
The time it takes for a request to travel from sender to receiver and back. Low latency is critical for real-time applications. Often in tension with throughput.
Load Balancer
Distributes incoming traffic across multiple servers to prevent any single server from being overwhelmed. Can use strategies like round-robin, least connections, or weighted distribution.
M
Message Broker
Middleware that receives messages from producers and delivers them to consumers. Decouples systems and enables asynchronous communication. Examples: Kafka, RabbitMQ.
Message Queue
A form of message broker where messages are stored in order and each message is consumed by exactly one consumer. Useful for task queues and work distribution.
Microservices
An architectural style where a system is split into small, independently deployable services, each owning its own data and communicating over APIs. Enables independent scaling and deployment, at the cost of distributed system complexity.
Monolith
A single deployable unit containing all the application's functionality. Simpler to develop and debug initially; can become hard to scale and change as it grows. Not inherently bad — many successful systems are monoliths.
N
Non-Functional Requirements (NFRs)
How a system performs — scalability, availability, security, performance, maintainability. These are often what make or break an architecture. NFRs are where most architectural decisions live.
P
Partition Tolerance
A system's ability to continue operating even when network communication between nodes is lost or delayed. In CAP theorem, this is the property you can't sacrifice in a distributed system.
Pub/Sub (Publish-Subscribe)
A messaging pattern where publishers send messages to a topic, and all subscribers to that topic receive copies. Unlike a queue, multiple consumers can receive the same message.
R
Reliability
The probability that a system performs its intended function without failure over a given period. Related to availability but distinct — a system can be available (responding) but unreliable (returning wrong results).
Replication
Copying data across multiple nodes for redundancy, availability, or read performance. Introduces the challenge of keeping replicas in sync.
REST (Representational State Transfer)
An architectural style for APIs using HTTP. Resources are identified by URLs, and operations map to HTTP verbs (GET, POST, PUT, DELETE). Widely used; stateless by design.
S
Scalability
A system's ability to handle growing load — more users, more data, more requests — without degrading performance. Horizontal and vertical scaling are the two main strategies.
Service Discovery
The mechanism by which services find each other in a dynamic environment (e.g. microservices where instances come and go). Can be client-side or server-side.
Sharding
Partitioning data across multiple databases or nodes, each responsible for a subset of the data. Enables horizontal scaling of databases.
SLA / SLO / SLI
- SLI (Service Level Indicator): A metric you measure, e.g. request latency.
- SLO (Service Level Objective): A target for that metric, e.g. 99th percentile latency < 200ms.
- SLA (Service Level Agreement): A contractual commitment to an SLO, with consequences if broken.
Stateless
A service that doesn't store any client state between requests. Each request contains everything the server needs to process it. Stateless services are much easier to scale horizontally.
T
Throughput
The number of requests a system can handle per unit of time. Often in tension with latency — optimizing for one can hurt the other.
Trade-off
Every architectural decision involves giving something up to gain something else. Speed vs. consistency. Simplicity vs. flexibility. Cost vs. resilience. Recognizing and articulating trade-offs is the core skill of an architect.
V
Vertical Scaling (Scale Up)
Adding more resources (CPU, RAM) to an existing machine. Simpler than horizontal scaling but has hard limits and creates a single point of failure.
💡 Tip: When you encounter a term in this collection that isn't here, that's a good sign — look it up, understand its trade-offs, and it'll stick better than any definition could make it.