# fivenines

> fivenines is a public learning library for working software engineers. It explains how real systems work from first principles, offers free practice, and includes build-your-own design workspaces with Pro.

## Key pages

- [Home](https://fivenines.dev): Product overview
- [Learn](https://fivenines.dev/learn): Start or continue a guided learning track
- [Library](https://fivenines.dev/library): All public theory articles
- [Pricing](https://fivenines.dev/pricing): Free and Pro access
- [About](https://fivenines.dev/about): Company and mission

## Published tracks

### [Build Your Own Redis](https://fivenines.dev/track/build-your-own-redis)

Redis-inspired in-memory data store built from key-value command execution through protocol handling, storage internals, persistence, replication, failover, and cluster sharding.

- [Single-Node Key-Value Core](https://fivenines.dev/problems/redis-single-node-key-value-core): Build GET, SET, and DEL around one in-memory dictionary while defining clear command, reply, and missing-key semantics.
- [RESP Protocol Parser](https://fivenines.dev/problems/redis-resp-protocol-parser): Parse incremental RESP frames safely across partial reads, nested values, and malformed input before dispatching commands.
- [Client Connection Lifecycle](https://fivenines.dev/problems/redis-client-connection-lifecycle): Trace each client from accept through buffered reads, command execution, queued replies, and connection teardown.
- [Event Loop](https://fivenines.dev/problems/redis-event-loop): Multiplex file readiness and timer work in one event loop while keeping handlers short enough to preserve responsiveness.
- [Command Table And Dispatch](https://fivenines.dev/problems/redis-command-table-dispatch): Drive validation, authorization, and execution from command metadata instead of hard-coding a separate request path for every command.
- [Redis Object Model](https://fivenines.dev/problems/redis-object-model): Separate logical value types from physical encodings so representation can change without changing command semantics.
- [Hash Table And Rehashing](https://fivenines.dev/problems/redis-dictionary-rehashing): Spread hash-table resizing across ordinary operations so rehashing avoids a single latency spike while lookups consult both tables.
- [Expiration System](https://fivenines.dev/problems/redis-expiration-system): Combine lazy expiration on access with sampled active cleanup so expired keys disappear without blocking the server.
- [Memory Limits And Eviction](https://fivenines.dev/problems/redis-memory-limits-eviction): Enforce maxmemory by selecting victims under an explicit eviction policy whose trade-offs match the workload.
- [Core Data Types](https://fivenines.dev/problems/redis-core-data-types): Choose encodings and operations for lists, hashes, sets, and sorted sets according to their access patterns and size.
- [Pipelining And Output Buffers](https://fivenines.dev/problems/redis-pipelining-output-buffers): Pipeline requests to reduce round trips while bounding per-client output buffers so slow consumers cannot exhaust memory.
- [Transactions](https://fivenines.dev/problems/redis-transactions-watch): Queue commands between MULTI and EXEC, and use WATCH to abort optimistic transactions when observed keys change.
- [Scripts/functions](https://fivenines.dev/problems/redis-scripts-functions): Execute server-side scripts atomically by blocking interleaving, while controlling runtime so one script cannot stall every client.
- [Pub/Sub](https://fivenines.dev/problems/redis-pub-sub): Fan published messages out to channel and pattern subscribers while accepting Pub/Sub's transient, at-most-once delivery semantics.
- [Streams](https://fivenines.dev/problems/redis-streams-consumer-groups): Use ordered stream IDs, pending-entry tracking, acknowledgements, and claiming to divide durable work among consumers.
- [RDB Snapshotting](https://fivenines.dev/problems/redis-rdb-snapshotting): Create point-in-time snapshots with fork and copy-on-write, balancing compact recovery files against snapshot cost and possible data loss.
- [AOF Persistence](https://fivenines.dev/problems/redis-aof-persistence): Use an append-only command log plus background rewrite to trade recovery fidelity against write amplification and file growth.
- [Startup Recovery](https://fivenines.dev/problems/redis-startup-recovery): Restore persisted state by loading an RDB snapshot or replaying AOF commands before accepting client traffic.
- [Replication: Full Sync](https://fivenines.dev/problems/redis-replication-full-sync): Bootstrap a replica from a consistent snapshot, then stream buffered writes so it catches up without losing changes made during transfer.
- [Replication: Partial Sync](https://fivenines.dev/problems/redis-replication-partial-sync): Resume replication from IDs, offsets, and a bounded backlog when history is available, falling back to full synchronization when it is not.
- [Failover Controller](https://fivenines.dev/problems/redis-failover-controller): Use independent monitors, quorum, and epochs to promote one replica without letting competing observers create split-brain.
- [Cluster Sharding](https://fivenines.dev/problems/redis-cluster-sharding): Partition keys into hash slots and use MOVED redirects so clients can discover which node owns each key.
- [Cluster Resharding](https://fivenines.dev/problems/redis-cluster-resharding): Move hash slots live with migrating and importing states, ASK redirects, and dual-node coordination that preserves availability.
- [track Redis-Like System](https://fivenines.dev/problems/redis-capstone-system): Integrate protocol parsing, event handling, data structures, persistence, replication, and clustering into one coherent Redis-like system.

### [Build Your Own PostgreSQL](https://fivenines.dev/track/build-your-own-postgresql)

PostgreSQL-inspired relational database built from sessions, SQL parsing, binding, planning, execution, heap storage, buffers, WAL, transactions, MVCC, indexes, vacuum, recovery, catalogs, extensibility, replication, and partitioning.

- [What a database is really promising](https://fivenines.dev/problems/postgresql-what-a-database-is-really-promising): A database earns trust by defending three contracts under pressure: acknowledged changes remain recoverable, concurrent state stays coherent, and declarative questions preserve their meaning as execution routes change.
- [Processes, memory, and the shared system](https://fivenines.dev/problems/postgresql-processes-memory-and-the-shared-system): PostgreSQL presents one database through many backend processes: each connection owns private working memory, while backends and background processes coordinate through shared memory and durable files.
- [The Wire Protocol and Session Lifecycle](https://fivenines.dev/problems/postgresql-the-wire-protocol-and-session-lifecycle): A PostgreSQL connection is a state machine: startup establishes identity, normal messages advance explicit query and transaction states, and errors, cancellation, and termination each have defined recovery consequences.
- [SQL as a Language of Relations](https://fivenines.dev/problems/postgresql-sql-as-a-language-of-relations): SQL fixes the desired relation while leaving PostgreSQL free to choose its execution order, provided every transformation preserves duplicates, null semantics, types, and observable ordering.
- [Parsing SQL into trees](https://fivenines.dev/problems/postgresql-parsing-sql-into-trees): Raw parsing establishes grammatical structure, not database meaning: tokens and precedence become a faithful tree while object identity, types, operators, and privileges remain unresolved.
- [Binding Names, Types, and Schemas](https://fivenines.dev/problems/postgresql-binding-names-types-and-schemas): Binding freezes SQL meaning for a statement: visible names become catalog identities, expressions receive concrete types and operators, and privileges are checked before strategy begins.
- [Turning queries into logical plans](https://fivenines.dev/problems/postgresql-turning-queries-into-logical-plans): Logical planning may rearrange an analyzed query only across proven semantic equivalences; predicates, joins, projections, and subqueries are opportunities until SQL or security boundaries make their order observable.
- [Costs, cardinality, and choosing a plan](https://fivenines.dev/problems/postgresql-costs-cardinality-and-choosing-a-plan): Physical planning is a decision under uncertainty: PostgreSQL prices semantically valid paths from estimated cardinalities, so correct results are guaranteed while good performance depends on statistical evidence.
- [Executors as Iterator Machines](https://fivenines.dev/problems/postgresql-executors-as-iterator-machines): Execution is demand-driven composition: plan nodes share a lifecycle and tuple interface, allowing streaming pipelines, blocking operators, visibility checks, and cleanup to cooperate without exposing their internals.
- [Rows, Pages, and Heap Storage](https://fivenines.dev/problems/postgresql-rows-pages-and-heap-storage): Heap storage gives each physical tuple version a page-and-item address; line pointers keep that address stable within a page, while logical row identity and version lifetime remain separate concerns.
- [Buffer Pools and the Memory-Disk Border](https://fivenines.dev/problems/postgresql-buffer-pools-and-the-memory-disk-border): Shared buffers maintain one coherent in-memory identity per cached page: pins protect frame lifetime, short synchronization protects contents, and the WAL rule constrains when dirty pages may cross to disk.
- [Write-Ahead Logging and the Durability Contract](https://fivenines.dev/problems/postgresql-write-ahead-logging-and-the-durability-contract): WAL decouples commit from data-page placement through two orderings: durable commit waits for required log records, and a dirty page may reach disk only after WAL that explains its state.
- [Transactions and the illusion of instant change](https://fivenines.dev/problems/postgresql-transactions-and-the-illusion-of-instant-change): Transactions make many physical traces carry one outcome: tuple metadata and transaction status determine whether work is committed or aborted, while WAL and later cleanup operate on separate schedules.
- [MVCC and reading the past](https://fivenines.dev/problems/postgresql-mvcc-and-reading-the-past): MVCC preserves a snapshot invariant: each reader combines tuple-version metadata with transaction outcomes to see one coherent past, while writers create future versions and vacuum later reclaims unreachable history.
- [Locks, Latches, and Coordination](https://fivenines.dev/problems/postgresql-locks-latches-and-coordination): Coordination primitives must match resource and lifetime: heavyweight locks defend logical claims, while LWLocks, spinlocks, and buffer content locks protect shared internals only for short critical sections.
- [Indexes as ordered shortcuts](https://fivenines.dev/problems/postgresql-indexes-as-ordered-shortcuts): A B-tree preserves ordered routes from keys to physical tuple candidates; it can narrow work or supply order, but heap and transaction state remain authoritative for MVCC visibility.
- [Maintaining indexes through change](https://fivenines.dev/problems/postgresql-maintaining-indexes-through-change): Index maintenance must never omit a candidate for a visible tuple; PostgreSQL may retain obsolete candidates for MVCC rechecks, use HOT chains when keys stay fixed, and remove dead routes later.
- [Vacuum and the Cost of History](https://fivenines.dev/problems/postgresql-vacuum-and-the-cost-of-history): Vacuum reclaims history only after a visibility-horizon proof shows no relevant snapshot can need it, then reconciles heap space, index routes, visibility metadata, and transaction-ID age.
- [Checkpoints and Crash Recovery](https://fivenines.dev/problems/postgresql-checkpoints-and-crash-recovery): A checkpoint bounds where redo must begin; recovery then compares ordered WAL with each page's state, reapplies missing effects, and restores committed history without treating the checkpoint as the commit guarantee.
- [Catalogs as the database about the database](https://fivenines.dev/problems/postgresql-catalogs-as-the-database-about-the-database): PostgreSQL describes itself with transactional catalog relations: stable identities and dependencies preserve structural meaning, while locks, visibility, caching, and invalidation make live DDL coherent.
- [Functions, Operators, and Extensibility](https://fivenines.dev/problems/postgresql-functions-operators-and-extensibility): PostgreSQL extensibility is a metadata contract: implementations join typed catalog interfaces, while declared semantic properties constrain every optimization and storage structure that trusts them.
- [Isolation Levels and Anomalies](https://fivenines.dev/problems/postgresql-isolation-levels-and-anomalies): Isolation levels define which concurrent histories applications may observe; PostgreSQL strengthens the contract from statement snapshots to stable snapshots to serializable histories enforced through possible abort and retry.
- [Replication and Streaming Change](https://fivenines.dev/problems/postgresql-replication-and-streaming-change): Streaming replication exports ordered history, but receipt, write, durable flush, and replay are distinct progress claims; availability, commit safety, and read freshness depend on which position the contract names.
- [Partitioning and distributed shape](https://fivenines.dev/problems/postgresql-partitioning-and-distributed-shape): Partitioning preserves one logical relation by proving which local children can contain a read and routing each write to one bound; indexing, replication, and sharding solve different problems.
- [The Whole Machine](https://fivenines.dev/problems/postgresql-the-whole-machine): PostgreSQL is a chain of handoff invariants: session context becomes bound meaning, equivalent plans become visible tuple work, and ordered physical changes become recoverable committed history.

### [Build Your Own Uber](https://fivenines.dev/track/build-your-own-uber)

A ride-exchange architecture evolved from a complete three-nines regional system through four-nines automation to selective five-nines critical flows.

- [The product: a ride exchange](https://fivenines.dev/problems/uber-the-product-a-ride-exchange): Model ride hailing as a two-sided, real-time marketplace whose core loop is request, quote, match, trip, payment, and feedback.
- [Non-functional requirements: nines math and the scale envelope](https://fivenines.dev/problems/uber-non-functional-requirements-nines-math-and-the-scale-envelope): Translate demand, latency, availability, durability, RPO, and RTO into numeric constraints that architecture decisions can be tested against.
- [The system skeleton](https://fivenines.dev/problems/uber-the-system-skeleton): Separate edge, identity, marketplace, trip, payment, communication, and data-platform responsibilities around a small set of authoritative state flows.
- [Identity and onboarding](https://fivenines.dev/problems/uber-identity-and-onboarding): Separate authentication, rider and driver profiles, document verification, and account state so onboarding checks do not leak into every service.
- [Maps, routing, and ETA](https://fivenines.dev/problems/uber-maps-routing-and-eta): Combine map data, routing, traffic signals, and continuous ETA correction while isolating uncertain predictions from trip truth.
- [Driver presence and location ingestion](https://fivenines.dev/problems/uber-driver-presence-and-location-ingestion): Ingest high-rate, ephemeral driver updates with freshness rules and spatial indexing so nearby-driver views remain useful without pretending every point is durable truth.
- [Quotes and pricing v1: surge as market clearing](https://fivenines.dev/problems/uber-quotes-and-pricing-v1-surge-as-market-clearing): Produce expiring price quotes from supply and demand, using surge to balance the market without rewriting an accepted trip's price.
- [The matching engine: clearing the market](https://fivenines.dev/problems/uber-the-matching-engine-clearing-the-market): Rank feasible driver–rider pairs under location, ETA, and marketplace constraints while keeping dispatch decisions explicit and auditable.
- [Trip lifecycle: the state machine of record](https://fivenines.dev/problems/uber-trip-lifecycle-the-state-machine-of-record): Make the trip state machine the source of truth, enforcing legal transitions and idempotent commands across request, match, pickup, and completion.
- [Payments, ledger, and payouts](https://fivenines.dev/problems/uber-payments-ledger-and-payouts): Record money movement in an immutable double-entry ledger while isolating processor retries, reconciliation, and driver payouts from trip state.
- [Notifications, chat, and masked calls](https://fivenines.dev/problems/uber-notifications-chat-and-masked-calls): Treat push, chat, and masked calling as asynchronous, privacy-preserving channels that support a trip without becoming its source of truth.
- [Ratings, history, support, and admin](https://fivenines.dev/problems/uber-ratings-history-support-and-admin): Build read models and privileged workflows around immutable trip history so support actions are auditable and operational tools stay off the hot path.
- [Infrastructure baseline: one region, three zones](https://fivenines.dev/problems/uber-infrastructure-baseline-one-region-three-zones): Start with one region spread across three zones, using stateless services and zonally redundant data to survive a single-zone failure.
- [Observability v1: golden signals and on-call](https://fivenines.dev/problems/uber-observability-v1-golden-signals-and-on-call): Instrument latency, traffic, errors, and saturation, then connect actionable alerts to an on-call response loop.
- [Data platform, BI, and reporting v1](https://fivenines.dev/problems/uber-data-platform-bi-and-reporting-v1): Move operational events into an analytical pipeline so reporting workloads cannot destabilize the transactional ride path.
- [Recap: what 99.9% buys — and what breaks](https://fivenines.dev/problems/uber-recap-what-99-9-buys-and-what-breaks): Recognize that a three-nines baseline tolerates hours of annual disruption and still fails under zonal loss, overload, and fragile dependencies.
- [SLOs, error budgets, and criticality tiers](https://fivenines.dev/problems/uber-slos-error-budgets-and-criticality-tiers): Give user journeys explicit SLOs and criticality tiers so scarce reliability investment follows impact and remaining error budget.
- [Hardening the topology](https://fivenines.dev/problems/uber-hardening-the-topology): Remove hidden single points of failure by adding zonal redundancy, independent dependencies, health-aware routing, and bounded failover.
- [Data layer: sharding and automated failover](https://fivenines.dev/problems/uber-data-layer-sharding-and-automated-failover): Shard state by stable ownership keys and automate fenced failover so growth and replica loss do not require unsafe manual intervention.
- [The event backbone: outbox, idempotency, replay](https://fivenines.dev/problems/uber-the-event-backbone-outbox-idempotency-replay): Publish state changes through a transactional outbox and make consumers idempotent so events can be retried and replayed safely.
- [Matching at scale: geo-sharded dispatch](https://fivenines.dev/problems/uber-matching-at-scale-geo-sharded-dispatch): Partition dispatch by geography, manage boundary spillover, and keep candidate search local enough to scale without missing viable drivers.
- [Resilience patterns: timeouts, breakers, shedding, degradation](https://fivenines.dev/problems/uber-resilience-patterns-timeouts-breakers-shedding-degradation): Combine deadlines, bounded retries, circuit breakers, load shedding, and graceful degradation so dependency trouble does not cascade.
- [Multi-region disaster recovery: active–passive](https://fivenines.dev/problems/uber-multi-region-disaster-recovery-active-passive): Replicate critical state to a passive region and define detection, fencing, traffic shift, RPO, and RTO for a controlled regional failover.
- [Safe change: canaries, flags, and reversible migrations](https://fivenines.dev/problems/uber-safe-change-canaries-flags-and-reversible-migrations): Reduce deployment risk with canaries, feature flags, backward-compatible schemas, and migrations that can be paused or reversed.
- [Observability v2: SLO-driven operations](https://fivenines.dev/problems/uber-observability-v2-slo-driven-operations): Turn user-facing SLIs into SLOs and error budgets that govern alerting, reliability work, and release pace.
- [Streaming data platform and real-time BI](https://fivenines.dev/problems/uber-streaming-data-platform-and-real-time-bi): Stream immutable operational events into replayable processing so real-time metrics and features do not couple analytics to production databases.
- [Fraud, security, and compliance](https://fivenines.dev/problems/uber-fraud-security-and-compliance): Layer identity, authorization, encryption, audit trails, and risk signals around sensitive ride and payment flows without overloading the hot path.
- [Recap: the four-nines checklist](https://fivenines.dev/problems/uber-recap-the-four-nines-checklist): Validate that every critical ride path has zonal redundancy, bounded failover, overload protection, observability, and safe-change controls.
- [Where five nines is worth it — and where it's waste](https://fivenines.dev/problems/uber-where-five-nines-is-worth-it-and-where-it-s-waste): Apply five nines only to safety- and trip-critical paths, allowing less critical analytics and convenience features to fail more cheaply.
- [Active–active multi-region with regional homes](https://fivenines.dev/problems/uber-active-active-multi-region-with-regional-homes): Assign each trip and user a regional home while serving traffic from multiple regions, avoiding cross-region write conflicts during normal operation.
- [Cell-based architecture: bounding the blast radius](https://fivenines.dev/problems/uber-cell-based-architecture-bounding-the-blast-radius): Group compute and data into repeatable cells so a hot market or failed dependency affects only its assigned riders and drivers.
- [State at five nines: quorum truth, ephemeral speed](https://fivenines.dev/problems/uber-state-at-five-nines-quorum-truth-ephemeral-speed): Use quorum-backed storage for authoritative state and disposable fast stores for location and presence, matching consistency cost to data semantics.
- [Static stability: the data plane outlives the control plane](https://fivenines.dev/problems/uber-static-stability-the-data-plane-outlives-the-control-plane): Precompute and cache routing and ownership decisions so existing rides continue when control-plane services are unavailable.
- [Client-side resilience: the app is part of the architecture](https://fivenines.dev/problems/uber-client-side-resilience-the-app-is-part-of-the-architecture): Make mobile clients retry safely, cache useful state, and communicate degraded service because intermittent networks are part of the system.
- [Chaos engineering and gamedays: rehearsing the theory](https://fivenines.dev/problems/uber-chaos-engineering-and-gamedays-rehearsing-the-theory): Use hypothesis-driven failure injection and gamedays to prove that detection, degradation, and recovery work under realistic conditions.
- [Observability v3: probes, client truth, and auto-remediation](https://fivenines.dev/problems/uber-observability-v3-probes-client-truth-and-auto-remediation): Combine synthetic probes, client telemetry, and guarded automation to detect failures invisible to server metrics and remediate known cases safely.
- [The operating model and the cost of a nine](https://fivenines.dev/problems/uber-the-operating-model-and-the-cost-of-a-nine): Treat additional availability as an ongoing staffing and complexity cost, supported by ownership, runbooks, incident learning, and capacity discipline.
- [The final architecture](https://fivenines.dev/problems/uber-the-final-architecture): Assemble cells, regional homes, durable event flows, layered state, observability, and safe operations into one selectively five-nines ride exchange.

### [Build Your Own Stock Exchange](https://fivenines.dev/track/build-your-own-stock-exchange)

A complete electronic trading venue evolved from three-nines operation through five-nines durability and low-latency fairness.

- [What a stock exchange actually does](https://fivenines.dev/problems/stock-exchange-what-a-stock-exchange-actually-does): Understand an exchange as an ordered market that accepts constrained orders, discovers prices, publishes trades, and hands obligations downstream.
- [The full requirements map](https://fivenines.dev/problems/stock-exchange-the-full-requirements-map): Map functional flows, scale, latency, consistency, availability, and recovery requirements before committing to component boundaries.
- [Reading the nines: availability as a budget](https://fivenines.dev/problems/stock-exchange-reading-the-nines-availability-as-a-budget): Convert availability percentages into concrete downtime and failed-request budgets before choosing an architecture.
- [Architecture of a complete exchange](https://fivenines.dev/problems/stock-exchange-architecture-of-a-complete-exchange): Decompose an exchange into order entry, risk, matching, market data, and post-trade boundaries connected by explicit event flows.
- [The life of an order](https://fivenines.dev/problems/stock-exchange-the-life-of-an-order): Trace an order through validation, risk, sequencing, matching, acknowledgement, market data, and post-trade processing.
- [The order book and price-time priority](https://fivenines.dev/problems/stock-exchange-the-order-book-and-price-time-priority): Represent bids and asks so the matcher always selects the best price first and preserves arrival order within each price level.
- [The order state machine](https://fivenines.dev/problems/stock-exchange-the-order-state-machine): Encode accepted, active, partially filled, filled, canceled, and rejected transitions so retries cannot produce impossible order states.
- [Order types and time in force](https://fivenines.dev/problems/stock-exchange-order-types-and-time-in-force): Translate order types and time-in-force rules into explicit matching constraints so execution behavior is deterministic and testable.
- [Auctions, halts, and safeguards](https://fivenines.dev/problems/stock-exchange-auctions-halts-and-safeguards): Use auctions, volatility controls, and trading halts to restore orderly price discovery when continuous matching becomes unsafe.
- [Determinism: the event log is the exchange](https://fivenines.dev/problems/stock-exchange-determinism-the-event-log-is-the-exchange): Make every matching decision a deterministic function of an ordered event log so replicas can replay and recover identical state.
- [Market data at scale](https://fivenines.dev/problems/stock-exchange-market-data-at-scale): Publish sequenced snapshots and incremental updates through a fanout path that lets consumers detect gaps and rebuild state.
- [Accounts, custody, and pre-trade risk](https://fivenines.dev/problems/stock-exchange-accounts-custody-and-pre-trade-risk): Keep matching fast and safe by checking balances, positions, limits, and custody constraints before an order reaches the book.
- [Post-trade: clearing and settlement](https://fivenines.dev/problems/stock-exchange-post-trade-clearing-and-settlement): Separate execution from clearing and settlement, carrying immutable trades into obligations, netting, and final asset transfer.
- [Scaling to millions of users](https://fivenines.dev/problems/stock-exchange-scaling-to-millions-of-users): Scale participants by partitioning session and market-data fanout while preserving a narrow, deterministically ordered matching core.
- [Operating at three nines: crash, restart, replay](https://fivenines.dev/problems/stock-exchange-operating-at-three-nines-crash-restart-replay): Achieve a credible three-nines baseline by persisting ordered events and rebuilding deterministic state after process crashes.
- [The four-nines contract: audit your SPOFs](https://fivenines.dev/problems/stock-exchange-the-four-nines-contract-audit-your-spofs): Audit every critical request path for single points of failure, including hidden dependencies shared across otherwise redundant components.
- [The hot standby: replicated state machines](https://fivenines.dev/problems/stock-exchange-the-hot-standby-replicated-state-machines): Replicate an ordered input log to a hot standby so deterministic replay produces a ready-to-promote copy of matching state.
- [Reliable messaging: gaps, NAKs, retransmits](https://fivenines.dev/problems/stock-exchange-reliable-messaging-gaps-naks-retransmits): Sequence messages and repair detected gaps with NAKs, retransmission, and snapshots instead of pretending packet delivery is perfect.
- [Sessions that survive failure](https://fivenines.dev/problems/stock-exchange-sessions-that-survive-failure): Decouple durable session identity and sequence state from individual gateways so clients can reconnect without duplicating or losing orders.
- [Change without downtime](https://fivenines.dev/problems/stock-exchange-change-without-downtime): Deploy compatible, reversible changes with canaries, dual-version protocols, and staged migrations so trading continues during upgrades.
- [Deciding who leads: failure detection without split-brain](https://fivenines.dev/problems/stock-exchange-deciding-who-leads-failure-detection-without-split-brain): Combine failure detection, quorum-backed leases, fencing, and epochs so only one matching leader can accept orders.
- [Degrade, don't die: overload protection](https://fivenines.dev/problems/stock-exchange-degrade-don-t-die-overload-protection): Protect order entry and matching with admission control and load shedding, degrading noncritical work before queues collapse.
- [Four nines at scale: multi-zone anatomy](https://fivenines.dev/problems/stock-exchange-four-nines-at-scale-multi-zone-anatomy): Reach four nines by spreading critical components across zones, removing shared failure domains, and automating bounded failover.
- [The four-nines architecture, assembled](https://fivenines.dev/problems/stock-exchange-the-four-nines-architecture-assembled): Assemble multi-zone redundancy, automated failover, durable logs, and overload controls into a coherent four-nines exchange.
- [Five nines where it counts — and nowhere else](https://fivenines.dev/problems/stock-exchange-five-nines-where-it-counts-and-nowhere-else): Reserve five-nines engineering for the trading paths whose failure causes the most harm, and give supporting systems cheaper targets.
- [Consensus in the hot path](https://fivenines.dev/problems/stock-exchange-consensus-in-the-hot-path): Keep consensus out of per-order execution where possible, using it to establish ownership while a single leader orders the hot path.
- [Losing a datacenter gracefully](https://fivenines.dev/problems/stock-exchange-losing-a-datacenter-gracefully): Survive regional loss with preplanned traffic shifts, fenced ownership, replicated state, and explicit recovery-point trade-offs.
- [Cells: capping the blast radius](https://fivenines.dev/problems/stock-exchange-cells-capping-the-blast-radius): Partition the exchange into self-contained cells so overload or failure in one market segment cannot consume the whole platform.
- [Gray failures and chaos drills](https://fivenines.dev/problems/stock-exchange-gray-failures-and-chaos-drills): Expose partial and ambiguous failures with targeted probes and chaos drills that verify detection, isolation, and recovery before production does.
- [The riskiest component is change](https://fivenines.dev/problems/stock-exchange-the-riskiest-component-is-change): Treat deployment as a failure mode and reduce its blast radius with staged rollout, compatibility, observability, and fast rollback.
- [The five-nines architecture, assembled](https://fivenines.dev/problems/stock-exchange-the-five-nines-architecture-assembled): Assemble cells, multi-region ownership, static stability, and disciplined operations into a five-nines design with bounded failure domains.
- [track: the whole exchange, end to end](https://fivenines.dev/problems/stock-exchange-capstone-the-whole-exchange-end-to-end): Connect order entry, risk, deterministic matching, market data, clearing, and recovery into one end-to-end exchange design.
- [Latency is a fairness property](https://fivenines.dev/problems/stock-exchange-latency-is-a-fairness-property): Control latency variance across participants because unequal access time can distort price-time priority even when matching is correct.
- [Measuring without lying](https://fivenines.dev/problems/stock-exchange-measuring-without-lying): Measure end-to-end latency with coordinated timestamps, percentiles, and realistic load so queues and tail behavior remain visible.
- [The millisecond rung: architecture-level latency](https://fivenines.dev/problems/stock-exchange-the-millisecond-rung-architecture-level-latency): Reach millisecond latency by shortening synchronous paths, bounding queues, colocating dependencies, and eliminating avoidable network hops.
- [The microsecond rung: mechanical sympathy](https://fivenines.dev/problems/stock-exchange-the-microsecond-rung-mechanical-sympathy): Reach microsecond latency by aligning data layout, CPU affinity, memory access, and network I/O with the hardware's actual costs.
- [Jitter: the tail is the product](https://fivenines.dev/problems/stock-exchange-jitter-the-tail-is-the-product): Treat tail latency and jitter as first-class outcomes because unpredictable delay undermines both throughput and participant fairness.
- [Fairness engineering](https://fivenines.dev/problems/stock-exchange-fairness-engineering): Turn fairness into enforceable ordering rules, synchronized ingress, and auditable timestamps rather than relying on average latency.
- [When nines fight microseconds](https://fivenines.dev/problems/stock-exchange-when-nines-fight-microseconds): Resolve reliability–latency conflicts by keeping the hot path minimal while moving replication and recovery work to carefully bounded boundaries.

### [Build Your Own Docker](https://fivenines.dev/track/build-your-own-docker)

A container engine built from isolation primitives through images, distribution, runtime, storage, networking, orchestration, and production hardening.

- [What Problem Does Docker Solve?](https://fivenines.dev/problems/docker-what-problem-does-docker-solve): Learn What Problem Does Docker Solve? while evolving MiniDock, a complete container engine designed from first principles.
- [Containers vs. Virtual Machines](https://fivenines.dev/problems/docker-containers-vs-virtual-machines): Learn Containers vs. Virtual Machines while evolving MiniDock, a complete container engine designed from first principles.
- [The Layered Runtime Architecture](https://fivenines.dev/problems/docker-the-layered-runtime-architecture): Learn The Layered Runtime Architecture while evolving MiniDock, a complete container engine designed from first principles.
- [Namespaces: The Walls](https://fivenines.dev/problems/docker-namespaces-the-walls): Learn Namespaces: The Walls while evolving MiniDock, a complete container engine designed from first principles.
- [Cgroups: The Meters](https://fivenines.dev/problems/docker-cgroups-the-meters): Learn Cgroups: The Meters while evolving MiniDock, a complete container engine designed from first principles.
- [The Security Sandwich](https://fivenines.dev/problems/docker-the-security-sandwich): Learn The Security Sandwich while evolving MiniDock, a complete container engine designed from first principles.
- [Anatomy of an Image](https://fivenines.dev/problems/docker-anatomy-of-an-image): Learn Anatomy of an Image while evolving MiniDock, a complete container engine designed from first principles.
- [Content Addressing](https://fivenines.dev/problems/docker-content-addressing): Learn Content Addressing while evolving MiniDock, a complete container engine designed from first principles.
- [Union Filesystems](https://fivenines.dev/problems/docker-union-filesystems): Learn Union Filesystems while evolving MiniDock, a complete container engine designed from first principles.
- [Building Images](https://fivenines.dev/problems/docker-building-images): Learn Building Images while evolving MiniDock, a complete container engine designed from first principles.
- [The Build Cache](https://fivenines.dev/problems/docker-the-build-cache): Learn The Build Cache while evolving MiniDock, a complete container engine designed from first principles.
- [Multi-Stage Builds](https://fivenines.dev/problems/docker-multi-stage-builds): Learn Multi-Stage Builds while evolving MiniDock, a complete container engine designed from first principles.
- [The On-Disk Stores](https://fivenines.dev/problems/docker-the-on-disk-stores): Learn The On-Disk Stores while evolving MiniDock, a complete container engine designed from first principles.
- [Registry Architecture](https://fivenines.dev/problems/docker-registry-architecture): Learn Registry Architecture while evolving MiniDock, a complete container engine designed from first principles.
- [Pull, End to End](https://fivenines.dev/problems/docker-pull-end-to-end): Learn Pull, End to End while evolving MiniDock, a complete container engine designed from first principles.
- [Push and Dedup](https://fivenines.dev/problems/docker-push-and-dedup): Learn Push and Dedup while evolving MiniDock, a complete container engine designed from first principles.
- [Tags, References, and Garbage](https://fivenines.dev/problems/docker-tags-references-and-garbage): Learn Tags, References, and Garbage while evolving MiniDock, a complete container engine designed from first principles.
- [The Container Lifecycle](https://fivenines.dev/problems/docker-the-container-lifecycle): Learn The Container Lifecycle while evolving MiniDock, a complete container engine designed from first principles.
- [docker run: The Full Picture](https://fivenines.dev/problems/docker-docker-run-the-full-picture): Learn docker run: The Full Picture while evolving MiniDock, a complete container engine designed from first principles.
- [Copy-on-Write at Runtime](https://fivenines.dev/problems/docker-copy-on-write-at-runtime): Learn Copy-on-Write at Runtime while evolving MiniDock, a complete container engine designed from first principles.
- [Supervision and Restart Policies](https://fivenines.dev/problems/docker-supervision-and-restart-policies): Learn Supervision and Restart Policies while evolving MiniDock, a complete container engine designed from first principles.
- [exec, attach, and logs](https://fivenines.dev/problems/docker-exec-attach-and-logs): Learn exec, attach, and logs while evolving MiniDock, a complete container engine designed from first principles.
- [Stopping Gracefully](https://fivenines.dev/problems/docker-stopping-gracefully): Learn Stopping Gracefully while evolving MiniDock, a complete container engine designed from first principles.
- [Health Checks](https://fivenines.dev/problems/docker-health-checks): Learn Health Checks while evolving MiniDock, a complete container engine designed from first principles.
- [Volumes, Binds, tmpfs](https://fivenines.dev/problems/docker-volumes-binds-tmpfs): Learn Volumes, Binds, tmpfs while evolving MiniDock, a complete container engine designed from first principles.
- [Volume Lifecycle and Drivers](https://fivenines.dev/problems/docker-volume-lifecycle-and-drivers): Learn Volume Lifecycle and Drivers while evolving MiniDock, a complete container engine designed from first principles.
- [Storage Drivers](https://fivenines.dev/problems/docker-storage-drivers): Learn Storage Drivers while evolving MiniDock, a complete container engine designed from first principles.
- [The Container Network Model](https://fivenines.dev/problems/docker-the-container-network-model): Learn The Container Network Model while evolving MiniDock, a complete container engine designed from first principles.
- [Bridge Networking](https://fivenines.dev/problems/docker-bridge-networking): Learn Bridge Networking while evolving MiniDock, a complete container engine designed from first principles.
- [Publishing Ports](https://fivenines.dev/problems/docker-publishing-ports): Learn Publishing Ports while evolving MiniDock, a complete container engine designed from first principles.
- [DNS and Service Discovery](https://fivenines.dev/problems/docker-dns-and-service-discovery): Learn DNS and Service Discovery while evolving MiniDock, a complete container engine designed from first principles.
- [Host, None, and the Driver Seam](https://fivenines.dev/problems/docker-host-none-and-the-driver-seam): Learn Host, None, and the Driver Seam while evolving MiniDock, a complete container engine designed from first principles.
- [Overlay Networks](https://fivenines.dev/problems/docker-overlay-networks): Learn Overlay Networks while evolving MiniDock, a complete container engine designed from first principles.
- [Compose: Declarative Applications](https://fivenines.dev/problems/docker-compose-declarative-applications): Learn Compose: Declarative Applications while evolving MiniDock, a complete container engine designed from first principles.
- [Dependency Ordering](https://fivenines.dev/problems/docker-dependency-ordering): Learn Dependency Ordering while evolving MiniDock, a complete container engine designed from first principles.
- [Swarm Architecture](https://fivenines.dev/problems/docker-swarm-architecture): Learn Swarm Architecture while evolving MiniDock, a complete container engine designed from first principles.
- [Services, Tasks, and Reconciliation](https://fivenines.dev/problems/docker-services-tasks-and-reconciliation): Learn Services, Tasks, and Reconciliation while evolving MiniDock, a complete container engine designed from first principles.
- [Events, Logs, and Metrics](https://fivenines.dev/problems/docker-events-logs-and-metrics): Learn Events, Logs, and Metrics while evolving MiniDock, a complete container engine designed from first principles.
- [Hardening MiniDock](https://fivenines.dev/problems/docker-hardening-minidock): Learn Hardening MiniDock while evolving MiniDock, a complete container engine designed from first principles.
- [track: The Full Map](https://fivenines.dev/problems/docker-capstone-the-full-map): Learn track: The Full Map while evolving MiniDock, a complete container engine designed from first principles.

## Access

Theory and practice are publicly readable. An account is requested to save learning progress. Build-your-own design problems, the D2 workspace, and AI feedback require Pro.