Learn
One path. Finish a lesson, pass the checks, then the matching Lab unlocks.
Spine0/20
Foundations
How a request travels, and why speed, load, and failure are different problems.
- Client vs serverA client asks. A server answers. Everything else in system design is about what happens between them when there are many clients.~6 min
- Request and responseA request carries intent. A response carries a result or an error. Time spent waiting is latency; unfinished work in flight is load.Locked
- Latency vs throughputLatency is how long one request waits. Throughput is how many requests you finish per second. You can have one without the other.Locked
- Availability vs consistencyAvailability means the system answers. Consistency means answers agree. When machines fail or lag, you often trade one for the other — in plain language, not slogan CAP.Locked
- Why we scaleWe scale because one machine runs out of CPU, memory, disk, or network — or because we do not want one machine to be a single point of failure.Locked
Building blocks
One component at a time: what it is, when to use it, and what it cannot do.
- App serverThe app server runs your logic: auth, validation, orchestration. It should be easy to copy. It should not be the only copy of user data.Locked
- Load balancerA load balancer sits in front of several app servers and spreads requests so no single instance is the only door — or the only crash.Locked
- DatabaseThe database is the source of truth. It is often the first real bottleneck and the hardest SPOF. Treat writes with respect.Locked
- CacheA cache is a fast, usually incomplete copy of data. It cuts load and latency on the hot path. It can be wrong if you forget expiry and invalidation.Locked
- CDNA CDN is a cache at the edge: many locations close to users, great for static bytes and cacheable public responses.Locked
- Object storageObject storage holds files: images, videos, backups, exports. The database stores the pointer (URL, key), not the bytes.Locked
- Message queueA queue holds work to do later so the user request does not wait on slow or spiky jobs. Producers enqueue; workers dequeue.Locked
Numbers
Order-of-magnitude estimates so you can justify a cache — not a spreadsheet course.
Patterns
Recurring shapes: read-heavy vs write-heavy, fan-out, retries, and idempotency.
- Read-heavy vs write-heavyIf most traffic is reads, caches, CDNs, and replicas help. If most traffic is writes, those copies become expensive — queues and careful primaries matter more.Locked
- Fan-out on write vs readFan-out means one event becomes many deliveries. You can pay that cost when posting (write) or when reading a feed.Locked
- Retries and idempotencyNetworks fail. Clients retry. If the server did the work the first time, a retry must not double-charge. That property is idempotency.Locked
First systems
Four complete designs. Depth over a catalog of interview logos.
- URL shortenerWrite a long URL, get a short code. Reads (redirects) dwarf writes. Hash or generate an ID, store the mapping, cache hot codes.Locked
- Pastebin and file uploadSmall text can live in the database. Large pastes and files go to object storage; the DB keeps metadata and a pointer. CDN if the files are public and hot.Locked
- Rate limiterA rate limiter counts requests per key (IP, user, token) in a fast store and rejects overflow. It belongs at the edge of the API, not after the expensive work.Locked
- Simple group chatStore messages per room. Clients send via the API; other members fetch or receive a push. A queue fans out notifications. Do not start with a global social inbox.Locked
Labs unlocked by this path
- Label a request pathLocked
- Survive a database hiccupLocked
- Put a load balancer in frontLocked
- Insert a cache on the read pathLocked
- Put a CDN on static bytesLocked
- Keep bytes out of the databaseLocked
- Don't make the user wait on the jobLocked
- Read-heavy profile serviceLocked
- Design a URL shortenerLocked
- Design pastebin / uploadsLocked
- Design a rate limiterLocked
- Design a small group chatLocked