Open almost any “system design building blocks” article and you get a parts catalog: here’s a load balancer, here’s a cache, here’s a message queue, memorize them. It reads like a hardware store where every aisle insists you need what it sells. That’s exactly the wrong mental model — and it’s why people can name twenty components but still freeze when asked to design one real system.
Design isn’t assembling every part. It’s a sequence of trade-off decisions, where each answer earns you one component and rules out others. The system design building blocks matter, but only in service of the questions that select them. This post is the map from questions to components — the hub of the System Design Foundations series, with each block linking to a deeper post where one exists.
- A component you can’t justify is a liability, not a feature. Every block adds complexity you have to operate — add it only when a requirement forces it.
- Design flows from five questions, not a checklist: team count, event fan-out, read patterns, traffic shape, and tolerable staleness.
- Start simple and add on pressure — a modular monolith with one database handles far more than people expect.
Why a Parts List Fails You#
A list of components tells you what exists; it says nothing about what you need. And the failure mode of “learn all the parts” is over-engineering: teams bolt on a message queue, three services, and a distributed cache for an app that two people and one database could serve — then spend their quarters operating infrastructure instead of shipping. The AWS Well-Architected Framework makes the same point from the ops side: good architecture is about trade-offs against your requirements, not about collecting patterns.
So flip the order. Instead of “what components exist,” ask “what does this system actually need,” and let the requirements pull components in. The rest of this post is that flip made concrete.
The Five Questions That Pick Your Components#
Before you draw a single box, answer these. Each one points straight at a building block — and if the answer is “no,” you’ve just saved yourself a component you don’t have to operate.
Read the map top to bottom. How many teams need to ship independently decides your architecture style. Whether many consumers need the same events decides queue versus log. Whether the same data is read over and over decides whether you cache. How spiky or global your traffic is decides load balancing and CDN. How much staleness you can tolerate decides your consistency model. None of these is answered by knowing what a component is — only by knowing what your system needs.
Layer 1: Architecture Styles#
The first decision is the shape of the whole system, and it follows from one thing: how many people need to change the code at once. A monolith ships as one unit and is the fastest way to build; a modular monolith keeps that simplicity while enforcing internal boundaries; microservices split the system into independently deployable pieces once coordinating one codebase becomes the bottleneck; event-driven and serverless styles trade different costs again.
The 2026 default, echoing Fowler’s MonolithFirst, is to start with a modular monolith and split only when a measured pressure justifies it. The full decision — and why team size, not traffic, is what actually forces the split — is in Monolith vs Microservices.
Layer 2: The Building-Block Components#
Inside whatever style you pick, these are the parts you assemble. The trick is the last column: each has a reach for it when — and if that condition isn’t true, you skip it.
| Component | What it does | Reach for it when… |
|---|---|---|
| API gateway | Single entry point: routing, auth, rate limiting | You have several services or clients needing one front door |
| Load balancer | Spreads traffic across instances | One instance can’t take the load, or you need failover |
| Cache | Fast copy of hot data | The same data is read far more than it changes |
| Message broker | Moves work/events between services | Services must decouple, or events have many readers |
| Database (SQL / NoSQL) | Stores the source of truth | Always — the choice is which, driven by access patterns |
| CDN | Serves static assets from the edge | Users are global and assets are cacheable |
| Object storage | Holds large blobs (files, media) | You store files, not rows |
| Search index | Fast full-text / faceted search | Users search text your database can’t query fast |
Most of these already have their own deep-dive. The load balancer turns out to be an availability tool, not a distribution one. The cache looks trivial until you hit invalidation, the genuinely hard part. The message broker hides a fork between a queue that forgets and a log that replays. The database choice — SQL or NoSQL — comes down to access patterns, not scale. The API gateway is the front door that’s often confused with a load balancer. And the CDN and object storage are the delivery layer your app server should hand files off to. The remaining blocks earn deep-dives as the series grows.
Layer 3: Cross-Cutting Concerns#
These don’t sit in one box — they run through the whole design, and ignoring them is how systems pass the demo and fail in production. Scaling is horizontal (more instances) versus vertical (bigger instances). Consistency is the CAP trade — under a network partition you choose availability or strong consistency, not both. Observability (logs, metrics, traces) is what lets you debug a system you can no longer hold in your head. Resilience — timeouts, retries, circuit breakers — decides whether one failure stays contained or cascades. And rate limiting protects you from traffic, abusive or accidental, that would otherwise take you down.
The whole method in one line: don’t ask “what components should I add?” — ask “what does this requirement force?” A design is the set of components you were forced into, plus nothing.
The Same Blocks, Rearranged for AI#
Here’s the part that matters for InfoWok’s readers: an LLM or agent app is not a different universe. It’s these same building blocks, rearranged — with a few of the decisions pushed to their extremes.
The blocks are the same; the names changed. A production AI app still has a gateway out front, services behind it, a database, and a cache. The twist is the new members of each layer: an inference service (the expensive one), a vector database as the store for embeddings — see Vector Databases for RAG — and often an orchestration or control plane coordinating it all. If you can read the classic diagram, you can read the AI one.
The decisions shift to their extremes. The architecture-style question bends early because the GPU inference block scales on a curve nothing else shares. The caching question gets sharper and riskier because semantic caching can serve a confidently wrong answer. The database question gains a new answer — a vector store — for similarity search that no SQL index does well. Same five questions; louder consequences.
And agents add a block that isn’t a service at all. An AI agent decides its own path at runtime, which breaks the guarantees the rest of your components assume. That’s a genuinely new building block, and it’s why AI Agents vs Microservices exists — and why the classic pipeline that assembles retrieval, prompting, and inference is worth understanding first via What Is RAG?.
The AI-era version of the map: same five questions, but the inference service is your most expensive block (split it early), the cache can be semantic (tune it or it lies), and “which database” now includes “a vector one.” The method doesn’t change — the stakes on a few answers do.
How to Use This Map#
Put together, the workflow is short. Start from the requirements and run the five questions. Default to the simplest thing that answers them — usually a modular monolith, one database, no message broker, no cache. Then add exactly the components a question forced, and nothing else. When a new pressure shows up — a team collision, a read-heavy endpoint, an event several services need — come back to the map, and let that pressure pull in the next block. Designing well is mostly the discipline to not add the parts you can’t yet justify.
Quick Recap#
- System design is decisions, not parts. A component you can’t justify is complexity you’ll pay to operate.
- Five questions drive it: team count, event fan-out, read patterns, traffic shape, staleness tolerance.
- Three layers: architecture style, building-block components, cross-cutting concerns.
- Default simple, add on pressure — and in AI systems it’s the same map with a few answers turned up loud.
Conclusion#
The point of learning the system design building blocks isn’t to have every part memorized — it’s to know which question each one answers, so you reach for it only when the system asks. Anyone can list components. Design is the judgment to leave most of them out until a real requirement drags them in, then wire in the one that fits. Start with the questions, keep it as simple as the requirements allow, and let this map turn “what could I add?” into the far better question: “what does this actually need?”
Which building block have you seen added too early — a cache, a message queue, a second service — for a system that didn’t yet need it? I’d like to hear which one — and why.
- Monolith vs Microservices — Layer 1: the architecture-style decision, and why team size decides it.
- Kafka vs RabbitMQ — the message-broker fork: a queue that forgets vs a log that replays.
- Caching Strategies — the cache and its hard part, invalidation. More building-block deep-dives are on the way.
