Short, focused explainers on system design topics — the concepts people search for most, with links into the full course for depth.
"ACID" gets thrown around as a synonym for "a real database," but each letter is a distinct, separately-breakable guarantee — and knowing which one a given failure violates is what actually matters in practice.
The CAP theorem gets summarized so often as "pick two of three" that the actual, useful part — what it forces you to decide, and when — gets lost. Here's the version that's actually useful in a system design interview.
When a downstream service starts failing, the naive response — every caller just keeps retrying — makes things worse, not better. A circuit breaker is the pattern that stops the pileup.
A single database server has a hard ceiling — one machine's disk, memory, and CPU. Sharding is how you break past it: split the data across many independent databases instead of scaling one bigger and bigger.
When a system needs more capacity, there are exactly two ways to get it: make the machine you have bigger, or add more machines. Most real systems end up doing both — just not at the same time.
"Design Twitter" is not a question with one correct answer — it's a prompt to see how you think. Walking in without a repeatable structure is the single most common reason strong engineers freeze up in this interview format.
A load balancer distributes requests across servers so no single one gets overwhelmed. The interesting decision isn't "should I use one" — it's which layer of the OSI Model it operates at, because that choice has real consequences for speed, cost, and what it can actually do.
Rate limiting is a deliberately blunt tool: instead of trying to make every request cheap, it accepts that some requests get turned away, so the system stays up for everyone else.
REST and GraphQL are two different answers to the same question: how should an API expose data to a client? The real decision isn't "which is more modern" — it's whether you're willing to give up free HTTP caching for a query language that fetches exactly what the client asks for.
"SQL or NoSQL?" sounds like a technology choice. It's actually a question about how much structure and consistency you're willing to trade for flexibility and scale — and the honest answer for most systems is "some of each," not one winner.