How to Think About System Design

Most system design writing is aimed at one of two people: the candidate cramming for a FAANG interview, or the architect at a company with a billion users. I’m neither, and odds are neither are you. I build real products — a clinic SaaS, a homelab, a handful of apps that serve real users on a budget. This series is system design for that engineer: the one who has to make the call, ship it, and live with it on Monday.

Here’s the thesis the whole book rests on: system design has no right answers, only tradeoffs. Anyone who tells you “always use a queue” or “never shard” is selling certainty that doesn’t exist. The job isn’t memorizing the correct architecture — there isn’t one. The job is knowing which knobs exist, which direction each one turns, and what it costs you when you turn it.

The five axes

Almost every decision in this book is a trade along one or more of five axes. Buying more of one usually means spending another:

• Latency — how fast a single request feels. The user’s clock.
• Throughput — how much total work the system does per second. The system’s clock.
• Consistency — how up-to-date and in-agreement your data is across the system.
• Availability — the odds the system answers at all when asked.
• Cost & complexity — money, and the far more expensive currency: the operational burden your future self and teammates carry.

A cache buys latency and throughput by spending consistency (the cached copy goes stale). A read replica buys read throughput by spending consistency (replication lag) and cost (another server). Synchronous replication buys consistency by spending latency. Once you learn to see a design as a point in this five-dimensional space, “what’s the right architecture?” dissolves into the better question: which axis does this product actually need most, and what can it afford to give up?

The only two numbers that start every design

Before any diagram, two back-of-the-envelope numbers frame everything (we go deep on this in the next chapter):

• How much data? Rows, bytes, growth per month. This decides whether one MySQL box is fine for years (usually yes) or whether you’ll ever actually need to shard (usually no).
• How much traffic? Requests per second, and the ratio of reads to writes. A 100:1 read-heavy workload wants caching and replicas; a write-heavy one wants a very different shape.

Get these two roughly right and most “should I use X?” questions answer themselves. Skip them and you’ll cargo-cult a Netflix architecture onto an app with 200 daily users.

Resist the resume-driven architecture

The most expensive mistake in this field isn’t under-engineering — it’s building for a scale you don’t have and may never reach. Kubernetes, microservices, an event bus, and a sharded database for an app that a single modest server would serve happily for five years. Every one of those adds a moving part that can break at 3am, and none of them add a single user.

The senior instinct is the opposite: build the simplest thing that meets the actual requirement, and know exactly which axis you’d trade next when the requirement changes. This series is largely a catalog of those “next moves” — so that when traffic does force your hand, you reach for the right knob instead of the fashionable one.

How to read this book

The chapters build on each other, so front-to-back is the intended path, but each stands alone for review:

• The Physics — the constraints you can’t design away: latency numbers, and why scaling out demands statelessness.
• Consistency & Data — the CAP theorem, the menu of consistency models, and how replication makes the tradeoff concrete.
• Between Services — synchronous vs asynchronous communication, and idempotency: the single most useful pattern for surviving an unreliable network.
• Speed & Failure — caching patterns and their failure modes, and designing for the fact that everything eventually breaks.
• The User’s Clock — optimistic UI and prefetching, where perceived performance beats actual performance.
• Capstone — one real system designed end to end with the whole toolkit.

Where a topic has a practical wiring guide already, I’ll link to it rather than repeat it — this series is the why and when; the thirteen-layer stack tour is the how. They’re meant to be read together.

Conclusion

No right answers → only tradeoffs on 5 axes
Axes → latency · throughput · consistency · availability · cost/complexity
Start → how much data? how much traffic (read:write)?
Rule → simplest thing that meets the real requirement; know your next move

System design feels intimidating because it’s taught as a body of correct answers to memorize. It isn’t. It’s a small set of axes, a handful of patterns for trading between them, and the judgment to know which trade your product needs. Build that judgment and the diagrams draw themselves. Next: the numbers every engineer should know, and the napkin math that frames every design.