Distributed Systems
Consistency, consensus, replication and coordination — the CAP-theorem-shaped trade-offs at the heart of every large-scale system — together with the systems foundations underneath them: operating systems, networking, containers and the languages built for this work.
Handbooks 26
The System Design Fundamentals Handbook
The load-bearing ideas behind every distributed system — the CAP theorem and consistency models, concurrency and locking, partitioning and replication, and consensus and coordination — each tied to a real worked design you can study interactively.
CAP Theorem & Consistency Models
What a distributed system can promise when the network splits — CP vs AP, why "CA" is a myth, PACELC, and the full spectrum from linearizable to eventual consistency. Part of System Design Fundamentals.
Partitioning, Sharding & Replication
How one dataset becomes many — range vs hash partitioning, consistent hashing and virtual nodes, hot partitions, replication topologies, replication lag, and quorums. Part of System Design Fundamentals.
Consensus, Transactions & Coordination
How nodes that can crash still agree on one truth — majority quorums, Raft and Paxos, leader election, two-phase commit vs the saga pattern, and idempotency for exactly-once effects. Part of System Design Fundamentals.
The Kubernetes Handbook
The one idea under all the YAML — declare desired state, and a control loop makes reality match. Covers the orchestration problem, pods, deployments and replicasets, services and networking, the reconciliation loop and self-healing, the scheduler, config/secrets and health probes, autoscaling, and when you actually need Kubernetes.
The Observability Handbook
Seeing inside production — monitoring vs observability, the three pillars (metrics, logs, traces) and what each answers, structured logging, metric types and the cardinality trap, distributed tracing, the golden signals and SLIs/SLOs/error budgets, alerting on symptoms not causes, and correlating all three during an incident.
The Networking Handbook
How a request actually travels — the layered model, IP addressing and routing, TCP vs UDP, the TCP handshake and head-of-line blocking, DNS resolution and caching, HTTP/1.1 vs HTTP/2 vs HTTP/3 (QUIC), TLS/HTTPS, and why round-trip latency, not bandwidth, dominates.
The Git Internals Handbook
Learn the model and the commands become obvious. Git as a content-addressed database: blobs, trees and commits; branches as 41-byte files; the three trees behind add/commit/reset; what merge and rebase mechanically do (and why rewriting shared history is a law, not a preference); the reflog recovery recipe; packfiles.
The Docker Handbook
A container is a lie told by the kernel — namespaces (what a process sees) plus cgroups (what it uses), not a VM. Image layers and the cache-ordering rule that halves build times, multi-stage Dockerfiles that ship small, volumes vs bind mounts, name-based networking, Compose, and the handoff to Kubernetes.
The API Design Handbook
An API is a promise you keep for years. Choosing REST vs gRPC vs GraphQL honestly, resource-modeling REST so consumers can guess it, contract-first gRPC and protobuf evolution, the retry-safe semantics that survive real networks (idempotency keys, cursor pagination, structured errors), versioning without breaking clients, and why agent tool schemas are the newest API surface.
gRPC vs REST
Both let services talk, and you often want both. REST over HTTP/JSON is universal, cacheable and debuggable — the right skin for public APIs; gRPC uses typed protobuf over HTTP/2 for fast, streaming service-to-service calls. The audience-decides rule, a trade-off table, and the REST-at-the-edge, gRPC-inside pattern.
Cryptography for Engineers
Encryption from XOR up. The one-time pad — XOR each byte with a random, message-length, single-use key — is the only provably unbreakable cipher, and its three rules teach the whole subject. XOR is its own inverse (a⊕k⊕k=a), so decrypt is the same op; a zero key is the identity (why keys must be random); and the fatal mistake: reuse the key on two messages and c₁⊕c₂=p₁⊕p₂ — the key cancels and secrecy dies (the VENONA blunder). Scales to symmetric (AES) + public-key + nonces + TLS, and the engineer's rules: never roll your own, never reuse a nonce, secure randomness, hash passwords slowly. With worked math and runnable code.
The OAuth & Auth Deep Dive
How "Sign in with Google" lets an app act for you without ever seeing your password. OAuth swaps your credentials for a scoped, revocable token, delivered via a short-lived authorization code that's worthless on its own — turning it into a token needs a back-channel exchange the browser can't make. Two parameters guard the flow: state (a random value echoed back, blocking forged/CSRF responses) and PKCE (challenge = SHA-256(verifier), so a stolen code can't be redeemed without the secret). Plus authentication vs authorization, OIDC/ID tokens, and the traps (implicit flow, unvalidated tokens, wide scopes, token leaks). With worked math and runnable code.
The Operating Systems Fundamentals Handbook
How your machine runs hundreds of programs on a few cores and a fixed slab of RAM — by sharing what isn't enough. Two tricks carry the weight: round-robin scheduling slices CPU time into quanta so no process starves (paying for fairness in context-switch overhead), and virtual memory pages hot data into physical frames, faulting to disk on a miss and evicting the least-recently-used page (LRU) — so more frames means fewer faults. Plus the vocabulary (process/thread/context switch/system call/page fault/kernel vs user mode) and the traps (thrashing, over-threading, the million-to-one memory hierarchy). With worked math and a runnable scheduler + pager simulation.
The Linux Internals Handbook
Linux runs the world on one idea: everything is a file. A document, the keyboard, a socket, another program's output — all reached through a small integer (a file descriptor) with the same four calls: open, read, write, close. The descriptor table allocates the lowest free integer (0/1/2 = stdin/stdout/stderr), which is exactly how the shell redirects output; a pipe is a kernel FIFO whose two ends wire a | b so one tool's output becomes another's input; and fork/exec split process creation from program loading, opening the window where descriptors get wired. Plus the traps (fd leaks → EMFILE, pipe backpressure/deadlock, zombie processes). With worked math and a runnable fd-table + pipe.
The Compilers Basics Handbook
How a flat string like "2 + 3 * 4" becomes the meaning 14 (not 20). A compiler works in stages: tokenize the text into atoms, parse the tokens by precedence, then evaluate. Built around a tiny arithmetic pipeline — tokenize → shunting-yard → RPN eval — where the single precedence comparison is exactly where "*" is encoded to bind tighter than "+", and parentheses override it. Then scale the same skeleton to real languages (AST, semantic analysis, optimization, IR/codegen, LLVM) and dodge the traps (parsing nested grammars with regexes, conflating stages, ignoring error positions). With worked math and a runnable end-to-end calculator.
The Rust Handbook
Rust refuses the old memory trade-off (safe-but-slow GC vs fast-but-dangerous manual free) with one idea: ownership. Every value has exactly one owner, freed when the owner's scope ends — no garbage collector, no manual free, never freed twice. Assigning or passing a value moves it (invalidating the original, so no double-free/use-after-move); to share you borrow under one rule — any number of shared references XOR exactly one mutable — which makes data races impossible; and clone() deep-copies when you truly need two. All checked at compile time, so safety costs nothing at runtime. Plus the guarantees table and the traps (cloning to silence the checker, fighting instead of listening, reaching for unsafe/Rc/RefCell too early). With worked rules and a runnable borrow-checker model.
The Go Handbook
Go makes concurrency approachable with one motto: don't communicate by sharing memory; share memory by communicating. Instead of threads poking at locked shared state, cheap goroutines (start with "go f()", run hundreds of thousands, multiplexed onto a few OS threads) pass data through channels — typed pipes that carry the synchronization. The whole model hinges on one rule: when does an operation block? An unbuffered channel (cap 0) blocks a send until a receiver is ready (a rendezvous); a buffered channel (cap N) blocks only when full/empty; and a blocked op with no partner is a deadlock (which Go's runtime detects and panics on). Plus goroutine leaks and when a mutex is still the right tool. With worked rules and a runnable channel model.
Monolith vs Microservices
Microservices don’t remove complexity, they relocate it from the codebase into the network. Why the real trigger to split is organizational (Conway’s Law), not code size, and why "monolith first" is the pattern behind most successful splits.
Raft vs Paxos
Provably equivalent in power, radically different to implement: Raft bets on a strong leader to make consensus reasoning-friendly; Paxos’s more general, leaderless formulation is more flexible and notoriously hard to get right. Why etcd and Kubernetes chose Raft.
CP vs AP Databases
CAP theorem’s forced choice, precisely stated: CP systems refuse some requests to guarantee consistency during a partition; AP systems keep serving, possibly stale, data. Why this trade-off only bites during an actual partition, and how real systems pick per data type.
GraphQL vs REST
GraphQL vs REST, decided by who chooses the shape of the response: REST exposes many fixed resource URLs and the server decides what each returns; GraphQL exposes one endpoint and the client asks for exactly the fields it needs. Over- and under-fetching, HTTP caching vs the N+1 problem, versioning, and when each wins — plus why "REST services behind a GraphQL gateway" is so common.
Orchestration vs Choreography
Orchestration vs choreography for coordinating microservices, decided by where control lives: orchestration puts one central coordinator in charge of a workflow; choreography lets services react to events with no central controller. Central visibility vs loose coupling, the saga pattern, and when to use each.
Optimistic vs Pessimistic Locking
Optimistic vs pessimistic locking, decided by how likely two writers collide: pessimistic locks a row before editing so others wait; optimistic edits without a lock and checks a version on write, retrying on conflict. Contention, deadlocks, retry storms, and when each wins.
TCP vs UDP
TCP vs UDP, decided by whether every byte must arrive: TCP is connection-oriented and guarantees reliable, in-order delivery with flow and congestion control; UDP is connectionless and fires packets with no guarantees and almost no overhead. Head-of-line blocking, why real-time uses UDP, how QUIC/HTTP-3 gets both, and when each wins.
Process vs Thread
Process vs thread, decided by whether they share memory: a process is an independent program with its own isolated memory; a thread runs inside a process and shares its memory. Isolation and safety vs cheap, fast, shared-memory concurrency — creation and context-switch cost, crash blast radius, the Python GIL, and when to use each.
Roadmaps 7
System Design Roadmap
A visual transit-map roadmap for system design in 2026. From APIs, databases, caching, and load balancing through sharding, queues, consistent hashing, and consensus to end-to-end designs of Twitter, YouTube, and Uber. 18 stations across 3 tracks — Fundamentals, Building Blocks, Real Systems.
Backend Engineer Roadmap
A visual transit-map roadmap to become a backend engineer in 2026. From HTTP APIs, SQL, NoSQL, caching, and auth through API design, message queues, testing, and observability to Kubernetes, CI/CD, sharding, and reliability. 18 stations across 3 tracks — Foundations, Core Backend, Production.
DevOps Roadmap
A visual transit-map roadmap to become a DevOps engineer in 2026. From Linux, networking, Git, and Docker through CI/CD, Terraform, Kubernetes, and secrets to observability, SRE, GitOps, and cost. 18 stations across 3 tracks — Foundations, Core DevOps, Production.
Cloud / AWS Roadmap
A visual transit-map roadmap to learn cloud engineering on AWS in 2026. From EC2, S3, VPC, and IAM through serverless, containers, IaC, and messaging to Well-Architected, multi-region, cost optimization, and DevOps. 18 stations across 3 tracks — Foundations, Core AWS, Production.
Platform Engineer Roadmap
A visual transit-map roadmap to platform engineering — building the platform everyone else ships on. From Linux, networking, containers and cloud through Kubernetes, infrastructure-as-code, CI/CD, GitOps and observability to SRE, internal developer platforms, golden paths, FinOps and platform-as-a-product thinking. 18 stations across 3 tracks — Foundations, The Platform, Scale & Reliability.
SRE Roadmap
A visual transit-map roadmap to become a site reliability engineer in 2026. From Linux, networking and distributed systems through SLOs, error budgets, alerting, incident response and postmortems to reliability patterns, chaos engineering, Kubernetes reliability, automation and disaster recovery. 18 stations across 3 tracks — Foundations, Reliability Practice, Scale & Resilience.
Solutions Architect Roadmap
A visual transit-map roadmap to become a solutions architect in 2026. From cloud fundamentals, networking and data through the Well-Architected pillars, scalability, resilience, cost and integration patterns to requirements discovery, architecture decisions, stakeholder communication and the SA career. 18 stations across 3 tracks — Foundations, Designing Systems, The Craft.
System Designs 36
Design Uber
Build a planet-scale ride-hailing system. Learn how to handle real-time location tracking, matching algorithms, scalability, and payments.
Design a URL Shortener
Build a URL shortener (think Bitly or TinyURL). Learn how to mint unique short codes with base62, make the read-heavy redirect path sub-millisecond with caching, shard billions of mappings, and track clicks asynchronously.
Design a Rate Limiter
Build a distributed rate limiter. Learn where to put the check, how to key and tier limits, the token-bucket and sliding-window algorithms, why shared atomic counters in Redis avoid race conditions, and the fail-open vs fail-closed trade-off.
Design Ticketmaster
Build an event-booking system. Tackle the double-booking problem head-on: seat inventory, short-lived holds with TTLs, exactly-once purchases via ACID transactions, payment sagas with idempotency, and a virtual waiting room that tames the on-sale stampede.
Design a Message Queue
Build a distributed message queue like Kafka. See how an append-only commit log, partitions keyed for order, consumer groups with server-side offsets, leader/follower replication, controller-driven leader election, retention and compaction, and exactly-once guarantees fit together.
Design a Key-Value Store
Build a distributed key-value store like DynamoDB. See how consistent hashing places keys, how replication and tunable quorums (R + W > N) trade consistency for availability, how vector clocks resolve conflicts, and how gossip membership, hinted handoff and read repair keep it alive through failure.
Design a Distributed Cache
Build a distributed cache like Redis or Memcached. See how cache-aside shields the database, how consistent hashing shards across nodes, how TTL and LRU/LFU eviction bound memory, how replication and invalidation keep it correct, and how to survive cache stampedes and hot keys.
Design a Web Crawler
Build a distributed web crawler. See how a URL frontier drives the fetch–parse–enqueue loop, how a bloom-filter seen-set stops infinite re-crawling, how politeness and robots.txt keep you a good citizen, how DNS caching and content dedup remove bottlenecks, and how to shard the frontier by host and dodge traps.
Design Google Docs
Build a real-time collaborative editor. See how edits become tiny operations, how OT and CRDTs resolve concurrent edits so every copy converges, how ops broadcast over WebSockets, how an op log plus snapshots give history and recovery, and how presence, offline sync and per-document sharding fit together.
Design a Job Scheduler
Build a distributed job scheduler (cron at scale). See how a durable job store indexed by run time, a due scanner, a ready queue feeding a worker pool, idempotent at-least-once execution, leader election to avoid double-fires, retries with backoff and a DLQ, and time-wheel sharding fit together.
Design an ID Generator
Build a distributed unique ID generator like Twitter Snowflake. See why auto-increment and UUIDs fall short, how a 64-bit ID packs a timestamp, machine id and sequence to stay collision-free and time-sortable without per-ID coordination, how machine ids are assigned, and how clock skew is handled.
Design Airbnb
Build a lodging marketplace. See how listings and geo search with filters, per-listing availability calendars, atomic booking that never double-books, payment hold-and-capture with idempotency, event-driven reviews and reindexing, and read replicas fit together.
Design a Stock Exchange
Build a stock exchange matching engine. See how an in-memory order book with price-time priority matches orders, how pre-trade risk checks guard the core, how a single sequencer and single-threaded engine give deterministic low-latency matching, and how market-data feeds, journaling/replay, clearing and symbol partitioning fit together.
Design a Payment System
Build a payment system like Stripe. See how a payment is modeled as a state machine of authorize and capture, how idempotency keys prevent double-charges, how a double-entry ledger keeps every cent auditable, how tokenization shrinks PCI scope, and how async webhooks, reconciliation and a durable retryable worker handle slow banks and failure.
Design a Load Balancer
Build a load balancer like NGINX or HAProxy. Learn why you scale out instead of up, how one entry point fronts a pool of stateless servers, how balancing algorithms (round-robin, least-connections, weighted, hashing) pick a server, how health checks evict dead boxes, L4 vs L7 routing, and how to make the balancer itself redundant.
Design an API Gateway
Build an API gateway like Kong or Amazon API Gateway. See how one front door decouples clients from your microservices, how it routes by path, offloads authentication and rate limiting to the edge, aggregates responses (BFF) and caches hot GETs, stays stateless and pooled, and isolates a failing service with timeouts and circuit breakers.
Design DNS
Build the Domain Name System. See why one central name→IP table can't work, how a delegated hierarchy of root, TLD and authoritative servers splits the namespace, how a recursive resolver walks it, how caching with TTLs makes lookups instant, how replication and anycast make it DDoS-proof, and how GeoDNS, DNSSEC and propagation work.
Design a Distributed File System
Build a distributed file system like GFS or HDFS. See why one file server caps capacity and throughput, how huge files split into large chunks across chunkservers, how a single master serves only metadata while clients stream bytes directly, how rack-aware replication survives correlated failures, how a leased primary orders pipelined writes, and how the master is made recoverable.
Design a Metrics & Monitoring System
Build a monitoring system like Prometheus or Datadog. See why SSH-and-grep can't scale, how counters, gauges and histograms instrument the golden signals, pull vs push collection, storing the sample firehose in a time-series database, splitting alerting into a rule evaluator and an alert manager that dedupes and routes, dashboards, HA collectors and federation, and why you must monitor the monitor.
Design a Distributed Tracing System
Build a distributed tracing system like Jaeger or Honeycomb. See why metrics and logs can't explain one slow cross-service request, how spans sharing a trace id form a waterfall, how trace context propagates in headers across every hop, how spans are emitted fire-and-forget through agents to a collector, why tail-based sampling keeps the errors and slow traces, and how the trace store serves both assembly and search.
Design a Distributed Counter
Build a distributed counter for view counts and likes at massive scale. See why a single UPDATE row melts under write contention, how sharding into N sub-counters trades read cost for parallel writes, how batching through a stream cuts write volume, how a cached total makes reads O(1), how HyperLogLog counts uniques in a few KB, and how idempotency keys make increments exactly-once.
Design a Digital Wallet
Build a digital wallet like PayPal or Venmo. See why a mutable balance column is dangerous, how an append-only double-entry ledger makes balance derived and money conserved, how atomic debit+credit transfers survive a mid-transfer crash, how idempotency keys stop double-charges, how per-account locking prevents double-spend, how cross-shard transfers use sagas, and how pending/settled states and reconciliation handle slow bank rails.
Design a Distributed Lock
Build a distributed lock (mutual exclusion across machines) like Redis locks, Redlock or etcd/ZooKeeper locks. See why a "locked=true" flag deadlocks and races, how atomic acquire grants to exactly one, how a TTL lease auto-releases a dead holder, how ownership tokens make release safe, why fencing tokens are the real safety mechanism against pauses, and why correctness-critical locks need a consensus quorum.
Design a Service Discovery System
Build a service discovery system like Consul, etcd, Eureka or Kubernetes DNS. See why hardcoded IPs break in a dynamic fleet, how a service registry maps names to live instances, how self-registration and health checks keep it accurate, the client-side vs server-side discovery tradeoff, why the registry needs consensus (CP) or accepts AP staleness, and how caching and watches keep lookups fast and fresh.
Design a Flash Sale System
Build a flash-sale / limited-inventory system for a massive concurrent drop. See why read-then-decrement oversells, how admission control and a virtual waiting room pace the thundering herd, how an atomic inventory decrement guarantees exactly N buyers win, how reserve-then-confirm with a hold TTL and async order processing work, and how to tame the single hot inventory key with fairness and anti-bot defenses.
Design a Collaborative Editor
Build a real-time collaborative document editor like Google Docs, Notion or Figma. See why a whole-document lock kills concurrency, how naive position-based edits corrupt a document, how Operational Transformation's central sequencer works and where it bottlenecks, how CRDTs remove that bottleneck with causal, order-independent merges, why presence/cursors live outside the document's durable history, and how offline-first editing and tombstone garbage collection round out the design.
Design a Calendar System
Build a shared calendar like Google Calendar or Outlook. See why storing every recurring occurrence explodes storage, how RRULE-based recurrence is expanded at read time with exceptions layered on top, how free/busy conflict detection stays fast via interval overlap, the timezone/DST trap that can silently shift a recurring meeting by an hour, how invite/RSVP fan-out avoids blocking the organizer, how reminders scale via a time-bucketed trigger index, and how devices sync incrementally.
Design a Hotel Booking System
Build a hotel/room booking platform like Booking.com or Marriott. See why read-then-decrement inventory oversells rooms, how a multi-night stay needs an all-or-nothing atomic transaction across every date, how reserve-then-confirm with a hold TTL prevents both overselling and cart-abandonment loss, why dynamic pricing is cached rather than computed live, how search is split from the strongly-consistent booking path (CQRS), and how controlled overbooking is a business policy the same atomic system enforces.
Design a Dating App
Build a swipe-based dating app like Tinder or Hinge. See why a live full-table nearby scan doesn't scale, how a geospatial index plus a swiped-exclusion set fixes candidate generation, the mutual-match race condition and how a database uniqueness constraint guarantees exactly one match, how ranked feeds are precomputed rather than live, why blocking is deliberately the strictest-consistency path in the whole system, and how bot/fake-profile detection runs quietly, asynchronously, off the hot path.
Design a Ride-Matching Engine
Build the matching and dispatch engine at the heart of a ride-hailing platform — the specific subsystem deciding which driver gets which rider, not the trip lifecycle or payments. See why straight-line distance is a bad proxy for real ETA, why greedy one-at-a-time matching is globally suboptimal, how batch matching solves an assignment-optimization problem across a short window, surge pricing as supply/demand balancing, ingesting driver locations at write-heavy scale, and fairness for idle drivers.
Design a Logging Pipeline
Build the ingestion pipeline that collects, buffers and delivers logs from thousands of services — the write path, not the query/search side. See why synchronous writes to a central log server are dangerous, local agent buffering, bounded backpressure and overflow policy, batching for throughput, where structured parsing should happen, at-least-once delivery with dedup, sampling at high volume, and why a logging storm can take down the very system it was meant to observe.
Design an Email System
Build an email system like Gmail or Outlook. See why raw inbound mail can't land straight in a mailbox, retry-with-backoff for unreliable delivery across the open internet, layered spam/authentication filtering, per-user mailbox sharding, thread reconstruction via message headers instead of subject lines, delivery dedup and bounce-loop prevention, and IMAP-style incremental multi-device sync.
Design an Online Judge
Build a code-execution judge like LeetCode, Codeforces or HackerRank's backend. See why running submitted code inline is a security catastrophe, what real sandboxing has to guarantee beyond just a container, async queue-based execution for contest-scale bursts, verdict determination across hidden test cases, CPU-time (not wall-clock) resource limits for fairness, judge determinism, and fair queueing so one flood of submissions can't starve everyone else.
Design Webhook Ingestion at Scale
Build a reliable webhook ingestion pipeline — the backbone of every integration. Learn signature verification and replay protection, acknowledging fast with a durable queue, idempotent processing that turns at-least-once delivery into effectively exactly-once, bounded retries with a dead-letter queue, replay after a fix, and monitoring consumer lag and DLQ depth.
Design a Customer Data Integration Pipeline
Build the pipeline that ingests a customer’s messy data on almost every deployment. Learn source connectors (API, SFTP, database, change-data-capture), staging, validation and mapping to a canonical schema, quarantining bad rows instead of dropping them, incremental sync by checkpoint, idempotent upsert loads with backfill, and reconciliation that proves the data landed.
Design Multi-Tenant Customer Isolation
Serve many customers from one system without ever leaking data between them. Learn tenant context propagation, the data-isolation spectrum (row-level, schema-per-tenant, database-per-tenant), preventing noisy neighbors with per-tenant quotas, per-tenant encryption keys and config, and audit plus automated cross-tenant tests that make isolation provable.
Algorithm Games 1
Coding Challenges 6
Token Bucket Rate Limiter
The algorithm inside most production rate limiters — and it never runs a timer. Refill the bucket lazily from the time elapsed since the last request, cap at capacity, spend one token or reject. Two numbers of state per client, exactly like the Redis version. Solve it in Python or TypeScript.
Circuit Breaker
Stop one failing dependency from taking down the fleet: trip after consecutive failures, fail fast while open, probe once after the cooldown. Implement the closed → open → half-open state machine as a pure, testable replay. Solve it in Python or TypeScript.
Consistent Hashing Ring
How distributed caches decide which node owns a key — with tiny churn when nodes join or leave. Build a hash ring with virtual nodes and route keys clockwise. A provided hash keeps Python and TypeScript in sync. Hidden tests.
Raft Leader Election (Majority)
The heartbeat of the Raft consensus algorithm: a candidate becomes leader only by winning a strict majority of the cluster — the rule that guarantees at most one leader per term. Decide an election round. Solve it in Python or TypeScript, with hidden tests.
Vector Clock Merge
Vector clocks let processes with no shared time agree on which event caused which. The key operation: on receive, take the element-wise max of the two clocks, then tick your own entry. Solve it in Python or TypeScript, with hidden tests.
CRDT: Grow-Only Counter
A counter many replicas increment independently, with no coordination, that always converges to the same total after syncing — a G-Counter, the simplest CRDT. Merge per-replica payloads by element-wise max. Solve it in Python or TypeScript, with hidden tests.
Labs 11
Raft: The Election
Don't read about Raft — run the cluster. Five nodes start as followers with random election timers; when one times out it becomes a candidate, bumps the term, and asks the others for votes. Win a majority and you're leader, sending heartbeats that reset everyone's timers. Kill the leader and watch a new election fire. Leader election and split-vote handling, made playable, with theory and a quiz.
The Quorum Dial
Don't read about quorums — dial them. With N replicas, a write goes to W of them and a read consults R of them. When R+W>N the read and write sets are forced to overlap, so a read always sees the latest write — strong consistency. Drop below that and reads can miss the newest value. Slide R and W and watch a read go fresh or stale. Tunable consistency, made playable, with theory and a quiz.
Vector Clocks: Who Caused What
Don't read about vector clocks — trace them. Three processes with no shared clock each keep a vector counting events they know about. A local event bumps your own entry; sending attaches your vector; receiving merges by taking the element-wise max. Compare two vectors and you can tell whether one event caused the other — or whether they're truly concurrent. Watch causality emerge on a timeline, made playable, with theory and a quiz.
CRDT Merge: No Conflict
Don't read about CRDTs — merge them. Three replicas edit the same counter at the same time with no coordination, then sync in any order — and always converge to the exact same value. The secret is a merge that is commutative, associative, and idempotent (here, element-wise max of per-replica counts). Increment replicas independently, merge them, and watch every replica agree, made playable, with theory and a quiz.
The Rumor Mill: Gossip
Don't read about gossip protocols — start a rumor. One node learns an update; each round, every node that knows it tells a random peer. The knowledge spreads like an epidemic — doubling each round — so all N nodes hear it in about log N rounds, with no central coordinator and graceful tolerance of failures. Watch a single update sweep a whole cluster, made playable, with theory and a quiz.
The Load Balancer
Don't read about load balancing — distribute the traffic. A load balancer spreads requests across a pool of servers, but the strategy decides everything: round-robin cycles blindly, least-connections sends work to the least-busy server, and hashing pins each client to one server for stickiness. When requests have uneven cost, the naive strategies pile up on one box while least-connections stays smooth. Send traffic and watch the queues, made playable, with theory and a quiz.
The TCP Sawtooth
Don't read about TCP congestion control — watch the sawtooth form. A sender probes the network's capacity by growing its congestion window exponentially at first (slow start), then linearly (congestion avoidance). When a packet is lost, it halves the window and probes again. This additive-increase / multiplicative-decrease loop makes millions of independent senders converge to a fair, stable share. Grow the window, inject loss, and watch it recover — made playable, with theory and a quiz.
The DNS Journey
Don't read about DNS — watch a name resolve. Typing a domain kicks off a recursive walk down a global tree: your resolver asks a root server (which points to the TLD), the TLD server (which points to the authoritative server), and finally the authoritative server (which returns the IP). Then it caches the answer so the next lookup is instant. Resolve a name step by step and watch the cache short-circuit a repeat lookup, made playable, with theory and a quiz.
The TLS Handshake
Don't read about TLS — watch two strangers agree on a secret while everyone is listening. A certificate proves the server's identity, and an ephemeral Diffie-Hellman exchange lets client and server derive the same secret key from public numbers without ever sending it across the wire. Step through the messages, watch each side compute the identical secret, and see why an eavesdropper still can't read it — with real tiny-number DH math, a quiz, and theory.
The Git Object Graph
Don't read about how Git stores your code — build the object graph. Every commit is a snapshot, not a diff: Git stores file contents as blobs, directories as trees, and each commit points to a tree plus its parent. Everything is addressed by the hash of its content, so identical content is stored exactly once and unchanged files are shared across commits for free. Edit files, commit, and watch new objects appear and unchanged ones get reused — made playable, with theory and a quiz.
How a Regex Runs: The NFA
Don't read about regular expressions — run one, state by state. A regex compiles to a small state machine (an NFA), and matching a string means tracking the SET of states the machine could be in at once — following epsilon jumps and consuming one character at a time. Because it tracks a set instead of guessing and backtracking, it matches in linear time with no catastrophic blowups. Feed characters into the machine for a(b|c)*d and watch the active states light up — made playable, with theory and a quiz.
Interactive Tools 11
Consistent Hashing Visualizer
An interactive consistent-hashing playground. Add and remove nodes, tune virtual nodes, and watch keys remap around the ring in real time — see exactly why consistent hashing moves only K/N keys instead of reshuffling everything, and how virtual nodes smooth out hotspots.
Quorum (N/R/W) Explorer
Dial the replica count and the read/write quorum sizes and see at a glance whether reads are guaranteed strongly consistent (R + W > N), how many node failures you can survive, and where you land on the latency–availability spectrum. The tunable-consistency intuition, made tactile.
Availability (Nines) Calculator
Chain dependencies in series and parallel and watch the combined availability — and the yearly downtime it implies — fall out. Unlike single-service "nines" calculators, this one models the dependency graph, so you see how one shaky component drags down the whole system.
Bloom Filter Sizing
Enter how many items you expect and the false-positive rate you can tolerate, and get the optimal Bloom filter: bit-array size, memory footprint, number of hash functions, bits per item, and the actual FP rate you’ll hit. See why a Bloom filter needs only ~10 bits per item — no matter how many items — to answer membership at a fraction of a hash set’s memory.
Token Bucket Simulator
A live token-bucket rate limiter you can play. Set the bucket capacity and refill rate, then send requests by hand or turn on auto traffic — watch the bucket drain when you burst, refill when you pause, and reject requests once it hits empty. The algorithm behind almost every production rate limiter, made tactile.
SLO Burn-Rate Calculator
Pick an SLO (99% to 99.99%), a window, and your current error rate: get the error budget in minutes and failed requests, the burn-rate multiple, time-to-exhaustion at the current pace, and the Google-SRE multiwindow alert table with the rows that would fire highlighted.
Little's Law Calculator
Little's Law ties the three numbers every capacity plan rests on: the average number of in-flight requests, the throughput, and the latency. Solve for whichever you don't know — size a connection pool from QPS and latency, back out the latency a queue depth implies, or find the throughput a fixed worker count can sustain. Includes a utilisation read-out so you can see when you're driving the system into the danger zone.
Connection Pool Sizer
A database connection pool sizer built on Little’s Law. Enter your peak queries per second, average query latency, and how many application instances you run, and get the concurrency you actually need, a per-instance pool size with headroom, and a check against your database’s max-connections limit — so you neither starve requests nor exhaust the database.
Rate Limit Designer
A rate limiter designer. Enter the sustained rate you want to allow and how big a burst to tolerate, and get concrete token-bucket parameters (refill rate and capacity), the effective peak burst, and how the choice compares to fixed-window and sliding-window approaches — including the boundary-burst pitfall of fixed windows.
Sharding Planner
A database sharding planner. Enter your total data size and query rate, and what a single shard can hold and serve, and get the number of shards you need — the larger of the storage and throughput requirements, with growth headroom — plus the per-shard load and a reminder of what resharding later costs.
Exponential Backoff Calculator
An interactive exponential-backoff calculator. Set the base delay, multiplier, cap and retry count, then see the exact delay before every retry attempt, the worst-case total wait, and how full and equal jitter change the numbers — so you can size retries that recover fast without hammering a service that is already struggling.
About distributed systems
The moment one machine isn't enough, a new class of problem appears: parts fail independently, messages arrive late or out of order, and there's no single global "now". Distributed systems is the study of building reliable behaviour on top of that unreliable substrate — through replication, consensus, partitioning and coordination.
The trade-offs here are shaped by the CAP theorem: when the network partitions, you choose consistency or availability, not both. This topic threads the handbooks, system designs and interactive tools that make those trade-offs concrete — quorums, consistent hashing, leader election — the machinery behind every large-scale system you've used.
It also carries the layer underneath distribution, because you cannot reason about a distributed failure without it: operating systems and Linux internals, networking, containers and Kubernetes, and the systems languages (Rust, Go) and compiler foundations these systems are built on. One machine's behaviour is the unit you are replicating — when it is a mystery, so is the cluster.