System Design Master Template

The template is a default you specialize — not a diagram you memorize

The "master template" is the set of boxes that show up in almost every large web system — client, DNS, CDN, load balancer, API gateway, app servers, cache, database with replicas, message queue, object store, search, and monitoring. Its value is not that you draw all of it. Its value is that it is a default request path you can walk end to end, deleting or specializing each box against the actual requirements. The two things that make a design interview go well are exactly the two things this page drills: (1) trace one request through the whole path so nothing is hand-waved, and (2) justify each load-bearing box against its named alternative — why an L7 balancer and not L4, why a queue and not a synchronous call, why relational and not NoSQL. A box you cannot justify is a box you should not draw.

The component checklist

Keep this list in your head as the menu — then subtract down to what the problem needs:

• Client — browser / mobile / another service; where the request originates and the response lands.
• DNS — resolves the domain to an IP, often the nearest edge (GeoDNS / anycast).
• CDN — edge caches static and cacheable content close to users; forwards dynamic requests to origin.
• Load balancer — spreads traffic across healthy app servers; health-checks and ejects dead ones.
• API gateway — single entry point: authentication/authorization, rate limiting, routing, request shaping.
• App servers — stateless business logic, scaled horizontally behind the balancer.
• Cache — in-memory tier (Redis/Memcached) that absorbs hot reads before they hit the database.
• Database + replicas — the durable source of truth; a primary takes writes, replicas serve reads.
• Message queue — buffers and decouples heavy or async work (Kafka/RabbitMQ/SQS) from the request path.
• Object store — cheap durable blob storage for images/video/files (S3-style), usually fronted by the CDN.
• Search — an inverted-index engine (Elasticsearch) for full-text and faceted queries a relational DB is bad at.
• Monitoring — metrics, logs, traces, and alerts; the sense organs that make every box above operable.

The traced request path — one request, end to end

Follow a single "load my profile page" request through the numbered path (the numbers match the diagram below):

1. Client issues the request for example.com/profile.
2. DNS resolves example.com to the nearest edge IP (GeoDNS/anycast return the closest point of presence, cutting round-trip time).
3. CDN edge receives it. Static assets (CSS, JS, avatar image) are served directly from the edge cache. The dynamic profile request is a cache miss, so the edge forwards it to the origin.
4. L7 load balancer at the origin inspects the HTTP request and forwards it to a healthy app server (it has been health-checking them and skips any that are down or draining).
5. API gateway authenticates the caller (validates the token), enforces the rate limit for that user, and routes to the profile service. An unauthenticated or over-limit request is rejected here — before it ever touches the backend.
6. App server checks the cache first: GET profile:123. On a hit it returns immediately (step 9). On a miss it continues down.
7. The app reads from a DB replica (read traffic is spread across replicas to keep the primary free). Had this been a write — "update bio" — it would go to the primary, which then replicates to the followers.
8. Any heavy or non-blocking side effect — regenerating a thumbnail, sending a notification, updating a search index — is published to a message queue and returns instantly; a worker consumes it later and, when its result matters to future reads, writes it back to the cache (and to the object store for blobs).
9. The app writes the freshly-read profile into the cache (so the next request is a hit) and the response is returned back up the same path to the client.

The discipline here is that every arrow is a real hop with a real cost. If you cannot name what happens at a box, you do not need the box.

Pitfalls

• Cargo-culting every box. Drawing a CDN, a queue, and a search cluster for a system with 100 users adds failure domains and operations cost for no benefit. Start from the estimation (QPS, storage, read/write mix) and add a box only when a number demands it. A design that deletes boxes with reasons is stronger than one that adds them.
• Single points of failure. "One load balancer, one primary DB" is a single fault away from an outage. Every load-bearing box needs a redundancy story: paired/active-passive balancers, multi-AZ replicas, primary failover.
• Cache/DB consistency. The cache and the database can disagree. Stale reads after a write, dog-piling on a popular miss (thundering herd), and forgetting to invalidate on update are the classic bugs. Decide the write policy (write-through vs invalidate-on-write) and a TTL, and say so.
• Treating the template as the answer. It is the starting point. The interview signal is how you specialize it — sharding the DB, choosing consistency per data type, picking L4 vs L7 — not that you can recite the boxes.

When to use each load-bearing box — and when its alternative wins

This is the judgment layer. For each choice: reach for the first option when its row's left condition holds; the named alternative wins when the right condition holds.

Decision	Use the first when…	The alternative wins when…
Relational (SQL) vs NoSQL	You need multi-row ACID transactions, joins across entities, and the schema is stable and well understood (payments, orders, anything with invariants).	NoSQL wins for massive horizontal write scale, a flexible/evolving schema, or simple key-based access at huge volume (event logs, feeds, session/KV data) — trading joins and cross-row ACID for scale.
Cache-aside vs read-through	You want the app in control and the cache optional: on a miss the app reads the DB and populates the cache, so a cache outage degrades to slower-but-working (Redis + app code — the common default).	Read-through wins when you want one centralized load path and a thinner app: the caching layer itself loads from the DB on a miss (DAX, Ehcache) — simpler app code, but the cache is now in the critical read path.
L7 vs L4 load balancing	You need content-aware routing — by URL path, host, or header — plus TLS termination, sticky sessions, or a WAF (routing to microservices by path is the classic case).	L4 wins when you want raw throughput and the lowest latency, protocol-agnostic routing (any TCP/UDP), or TLS pass-through — it moves packets by IP/port without parsing the payload, so it is cheaper and faster.
Synchronous REST vs async message queue	The caller needs the result now — reads and simple CRUD where immediate success/error and low latency matter and the work is fast.	A queue wins when work is heavy, slow, bursty, or fan-out: it decouples producer from consumer, absorbs spikes (back-pressure), and gives durable retries — at the cost of eventual, not immediate, completion.
CDN vs origin-only	Content is cacheable and users are geographically spread with high read volume — the edge cuts latency and offloads the origin (images, video, static assets, popular GET responses).	Origin-only wins when content is highly dynamic/personalized/uncacheable, traffic is low, or users sit in one region — then the CDN's cost and cache-invalidation complexity buy little.
Single-primary vs multi-primary replication	You want simplicity and no write conflicts: one primary takes all writes, replicas scale reads. The default for the vast majority of systems.	Multi-primary wins when you need low-latency or highly-available writes in multiple regions — but you must resolve write conflicts (last-write-wins or CRDTs), which is genuinely hard.

Takeaways

• The template is a default request path to specialize, not a diagram to memorize — subtract boxes the requirements do not justify.
• Be able to trace one request end to end: DNS → CDN → L7 balancer → gateway → cache → replica/primary → queue → response. Every arrow is a real hop with a real cost.
• For each load-bearing box, know the named alternative and the crossover condition — SQL vs NoSQL, L7 vs L4, cache-aside vs read-through, sync vs queue. That judgment is the interview signal.

---

Synthesized from Grokking the System Design Interview (DesignGurus), ByteByteGo, Designing Data-Intensive Applications (Kleppmann), and Hello Interview; architecture diagram and traced request path hand-authored as SVG. Re-authored/Deepened for this guide.

I just read a lesson on **System Design Master Template** (System Design) and want to truly understand it. Explain System Design Master Template from first principles using ONE vivid real-world analogy and a visual mental model — draw it as ASCII art or a clear step-by-step diagram — with a concrete example using real numbers. Then ask me one question to check I got the mental picture, and wait for my reply. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Teach me **System Design Master Template** interactively. Ask me ONE guiding question at a time, wait for my answer, and adapt to my confusion — build the idea with me step by step instead of explaining it all at once. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Quiz me on **System Design Master Template** with 5 questions, easy to tricky, ONE at a time. Tell me if each answer is right; at the end, explain clearly what I got wrong and why. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Help me remember **System Design Master Template** for the long term: give the one-sentence intuition, a memorable hook/mnemonic, a tiny worked example, and 3 active-recall flashcards (Q -> A). If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.