The discipline of deciding how services, databases, and the connections between them hold up once real traffic shows up — and the four goals every design gets judged against.
Scoping a design problem before drawing a single box: functional vs. non-functional requirements, and back-of-the-envelope capacity estimates.
HLD vs. LLD, and the RESHADED framework for structuring an answer to any open-ended "design X" prompt.
Eventual, causal, sequential, and strict consistency — four different promises about what a reader sees after a write.
Why every distributed data store eventually has to choose between a possibly-stale answer and no answer at all.
The spectrum of ways a node can fail, and the two workhorse techniques — replication and checkpointing — used to survive it.
One codebase that does everything, or many small services that each do one thing — and what each choice actually costs.
Blocking for a response is easy to reason about and slow to scale — firing and forgetting is fast and easy to lose data with.
Request-response covers most client-server traffic — until a feature needs the server to speak first. HTTP/REST, WebSocket, and RPC compared.
An API isn't just a URL scheme — it's a contract that has to survive retries, versions, and failures gracefully.
The choice rarely determines whether a feature is possible — it determines how much friction the team fights for the system's whole lifetime.
The guarantees that keep a multi-step write from leaving a database in a half-finished, contradictory state.
Single-leader, multi-leader, and leaderless replication — keeping multiple copies of the same data close enough to identical.
Splitting a dataset that's too large for one machine across many: vertical vs. horizontal, key-range vs. hash-based.
Plain hash % n reshuffles almost everything when the cluster changes size. Consistent hashing makes only a small slice move.
Two operations, get and put, and a design built around scaling that simplicity to enormous throughput.
Columnar stores for analytics, time-series databases, blob storage, and search-oriented stores — the workloads that don't fit SQL or NoSQL neatly.
The distributed, heavily-cached lookup service that turns a name every request starts with into an address every request actually needs.
The component that decides, per request, which of many backend servers actually handles it — and keeps working when some of them don't.
Physical distance is a latency floor no server capacity fixes — a CDN's whole job is shrinking that distance.
Saving repeated, expensive work inside the application itself — and the policies that decide what stays in memory and what gets evicted.
Capping how fast one client can hit a service, before that client degrades it for everyone else.
A single-server queue is a throughput ceiling and a single point of failure — spreading it across machines fixes both.
One event, many independent listeners — without the publisher needing to know who's listening or how many there are.
Auto-increment works great on one database. The moment data is sharded, something else has to guarantee uniqueness across all of them.
Every fault-tolerance technique in this track assumes something is watching for failure. This is that watcher.
Work that shouldn't run inline with a request needs somewhere else to run — and something to decide where and when.
On one machine, "check the logs" means one file. Across dozens of services, it needs a whole pipeline.
A relational LIKE query doesn't scale to millions of records, doesn't rank by relevance, and doesn't tolerate a typo.
A single counter row can only absorb so many concurrent increments before it becomes the bottleneck.
A small enough problem to fully design end to end — and one that touches caching, key-value storage, and unique ID generation all at once.
The one moment in checkout where a real design decision — inventory before payment — prevents selling the same last item twice.
Real-time delivery and never losing a message pull the design in two directions — the interesting part is reconciling them.
The naive design breaks the moment one account gets a million followers — the fix is choosing a strategy per author, not globally.
A write path (ingest and process huge files) and a read path (stream smoothly to millions) that have almost nothing in common, working together.