Loading
Loading
Large systems are not built out of clever code. They are built out of a small number of components arranged to make specific trade-offs, and the skill is being able to say which trade-off you are making and why. This track builds the vocabulary first, then the components, then the arrangements — and every lesson's diagram is data you can read as text, not a picture.
Up next: What Scale Actually Means
The words the rest of the track is written in: scale, latency, throughput, availability and the difference between them.
The path a request takes before your code runs, and the four places you can intervene on it.
Where state lives: relational and non-relational stores, indexes, replicas, partitions and caches.
What changes when the network is between your components: CAP, consistency models, coordination and queues.
Running the thing: where code executes, how services find each other, and how you see what happened.
Monolith, modular monolith, microservices and event-driven — as a sequence of trades rather than a ranking.
What happens below the query: index structures, transaction isolation, inverted indexes for search, and where large files belong.
Two ways to keep data findable, and why every index you add is a tax on every write.
What 'isolated' really promises, the anomalies each level allows, and how MVCC lets readers and writers stop blocking each other.
Inverted indexes for full-text search, local versus global secondary indexes, and keeping a derived index in step with its source.
Metadata in the database, bytes in object storage, uploads that bypass your servers, and a CDN in front of the reads.
Splitting data across machines, caching it without serving lies, and staying upright when more work arrives than you can do.
Hash versus range sharding, why hash-mod-N is a trap, and how to survive hot keys and resharding.
Where caches sit, how each write strategy behaves under failure, why hit ratio is non-linear, and how to stop a stampede.
Token buckets, leaky buckets and sliding windows; bounded queues; and shedding load before overload turns into collapse.
Keeping a system correct when its parts are slow, dead or disagreeing: timeouts and retries, consensus, and recovering from the failures you could not prevent.
A remote call can succeed, fail, or leave you not knowing. Most reliability bugs live in the third case.
Getting several machines to agree on one fact, even when some are dead and the rest cannot tell which.
Containing the failures you cannot prevent, and getting back from the ones you could not contain.
Six complete designs, each worked in interview order: requirements, estimates, API, data model, diagram, deep dives, trade-offs and scaling.
A home timeline of posts from people you follow, and the central choice: do the work when someone posts, or when someone reads?
Millions of open connections, messages that must arrive once and in order, and presence that is cheap enough to keep running.
Uploading, transcoding and serving video to every kind of screen, where the bandwidth bill shapes the whole design.
A store that keeps answering when nodes fail: partitioning, replication, tunable quorums and what to do when two writes collide.
Fetching a billion pages a month without overloading anyone's server, fetching the same page twice, or getting lost in an infinite calendar.
Moving money correctly matters more than moving it fast: idempotency end to end, a double-entry ledger, and reconciliation against the outside world.