Foundations

The fundamentals that sit under every design — the numbers, primitives, and habits you reach for before drawing a single box.

Sub-topics

• Estimation — Back-of-the-envelope math: turning users and payloads into QPS, storage, bandwidth, and cache — the arithmetic that picks an architecture.
• Method — How to approach a problem under pressure: frameworks, phase budgets, and the moves that separate a strong answer from a memorized one.
• Consistency — What it means for replicated data to agree: consistency models, quorums, and the CAP/PACELC trade-offs that decide what a read is allowed to see.
• Traffic — Shaping and defending the flow of requests: rate limiting, load shedding, back-pressure, and the algorithms that decide what gets through.
• Delivery — Getting a message — or its effect — to happen exactly once over a network that loses, duplicates, and reorders: delivery semantics, idempotency, and the exactly-once illusion.
• IDs — Naming things uniquely when there is no single machine to ask: distributed identifiers, time-ordered keys, and coordination-free generation.
• Scaling — Growing a system from one box to millions of users: the ordered sequence of bottlenecks and the remedy each one forces — split, replicate, cache, autoscale, shard, decouple.
• Hashing — Turning keys into positions: how hash functions place data on machines, and how to move as little as possible when the machines change.

Explainers

• Back-of-the-Envelope: the Numbers That Design Systems — Before you draw a box, you do the arithmetic. Powers of two, the latency ladder, and a live calculator that turns daily users and payload size into QPS, storage, bandwidth, and cache — every formula shown.
• Consistency, Quorums & CAP — Replication forces copies to disagree. The consistency ladder, the N/W/R quorum rule (W+R>N), and CAP stated precisely — the real choice is C-vs-A only during a partition — turned live on a 5-replica cluster.
• How to Design a System in 60 Minutes — A system design interview is not a memory test — it is four phases on a clock. Restate the problem, commit to one design, go deep where it matters, then break it on purpose. The framework, drawn as an interactive script you scrub minute by minute.
• Rate Limiting: Four Algorithms, Honestly Compared — Token bucket, leaky bucket, fixed window, sliding window — one bursty arrival pattern replayed through all four at once, every verdict computed from the real algorithm. Where each one lets a burst through, and what it costs to remember the past.
• Idempotency & the Exactly-Once Illusion — Over a lossy wire, “did it happen?” is unanswerable — so retries are the default reality. Exactly-once delivery is impossible; exactly-once effects are not. The property that buys them back is idempotency, drawn and computed.
• Unique IDs at Scale — A single auto-increment counter is trivial — until you shard and it becomes the hardest thing in the system. Watch the fix: pack a clock, a machine id, and a per-millisecond counter into 64 bits, with a scrubbable Snowflake bit-strip and clock-skew you can break.
• From One Server to Millions of Users — The scaling journey as a playable timeline. Start with everything on one box, then let each real bottleneck force the next move — split the database, load-balance a stateless web tier, add read replicas, cache, autoscale across zones, shard, and decouple write bursts with queues.
• Consistent Hashing — Add a machine to a sharded system and plain hash-mod-N reshuffles almost everything. Consistent hashing puts the nodes on the same ring as the keys — walk clockwise to the owner — so a membership change moves only one arc, and virtual nodes even out the load. Drawn, computed, and animated.