Case-study and scenario index

The course uses cases to connect requirements to mechanisms. A case is not a product recommendation. Documented implementation facts are separated from constructed workloads and architectural interpretation. A historical paper describes the architecture and measurements reported at publication, not every capability of a current service.

How to read a case

Follow five questions through the explanation: what must remain true, which work is common, where authority lives, which failures are covered, and where the remaining cost goes. Compare alternatives under the same invariant and acknowledgment contract before comparing speed. A solution that weakens durability or allows temporary overselling may be useful, but it implements a different contract.

Numerical scenarios are local to their lessons unless explicitly carried forward. A 100,000-request flash-sale illustration and a 20,000-transaction reference design are not asserted to be measurements of the same deployment. Rates of attempts, accepted transactions, storage work, and delivered messages remain distinct.

Architectural case studies

Recurring scenarios

A unique item’s ownership

A sword has one stable identity and one valid location or owner. It can be in a chest, held by a player, or in an explicitly modeled transfer state. A transaction must not leave two authoritative owners or remove the only ownership record accidentally.

The scenario first motivates data modeling, then exposes the difference between guarded updates, atomic transactions, retry identity, and client-visible copies. Later it crosses partition and geographic boundaries. The same invariant makes it possible to identify which optimization is transparent and which changes the product contract.

Primary locations: Lessons 1, 7, 19, 20, 30, 37, and 48.

A contended marketplace

Many requests compete over a small amount of stock. Catalog reads can be distributed easily while the authoritative stock transition remains hot. Retries increase attempts without increasing available items. A short protected transition can be more valuable than adding workers that wait for the same state.

The scenario connects skew, critical-section duration, locks, optimistic retries, deterministic execution, admission, and regional rights allocation. Every accepted sale must preserve the stated stock invariant. Allocating independent quotas is a legitimate alternative only when quota exhaustion and rebalancing behavior are part of the specification.

Primary locations: Lessons 1, 6, 18, 20, 22, 29, 34, 38, and 48.

Payments and external effects

A database transaction records a purchase while a payment provider, message service, or shipping system operates outside its atomic boundary. Communication can fail after a remote effect occurs. Local rollback cannot reverse every external event.

The explanations follow idempotency keys, durable results, transactional outboxes, consumer deduplication, compensation, and reconciliation. They distinguish a retry-safe database operation from a guarantee across arbitrary providers. No example claims that a broker delivery label makes all downstream effects exactly once.

Primary locations: Lessons 5, 19, 25, 30, and 37.

An on-call roster

At least one doctor must remain on call. Two transactions each observe another available doctor and independently update different rows. Their writes do not directly conflict, but their decisions share a predicate. The resulting write-skew history makes snapshot isolation’s limitation concrete.

The complete explanation identifies why no valid serial execution of the same transaction logic produces both departures. It then compares protecting the shared condition through stronger isolation, explicit locking, or a deliberate guard record. This is an invariant example rather than a lesson about medical operations.

Primary locations: Lessons 7, 20, 21, and 26.

A partitionable multitenant service

Most operations stay within one tenant, while tenant sizes and request rates are uneven. The service can exploit independent ownership but must handle large tenants, secondary access paths, cross-tenant operations, and noisy neighbors.

The scenario connects composite keys, statistics, query plans, sharding, resource accounting, authorization, and schema evolution. Its central distinction is between logical isolation and physical resource isolation. One tenant’s scan or retention horizon can harm another even when their records never conflict logically.

Primary locations: Lessons 10, 16, 29, 35, 37, 40, 41, and 48.

A realtime shared world

Players submit intent to an authoritative state transition. Nearby clients receive relevant state, while presentation needs to remain smooth across network delay and jitter. Inventory and ownership can require durable correctness even when intermediate animation or movement signals have different lifetimes.

The explanation separates transaction execution from delivery and rendering. It examines snapshot alignment, subscription fan-out, current state versus event history, interest boundaries, and the fact that a local cache can be fast while containing an older observation. Engine speed and gameplay prediction address different stages of the user-visible path.

Primary locations: Lessons 1, 4, 18, 32, 33, 47, and 48.

A reporting scan beside interactive transactions

A large scan consumes memory bandwidth, buffer capacity, temporary storage, or retained versions while short transactions need predictable response time. The final report can be small even though its input and intermediate work are large.

The scenario connects cache admission, physical operators, cardinality estimates, distributed exchanges, columnar layout, and resource groups. It explains why the same engine can execute both workloads correctly while requiring explicit isolation or placement to meet both performance objectives.

Primary locations: Lessons 1, 9, 12, 15–17, 31, 35, and 47.

A failed or paused leader

A participant becomes unreachable, a new authority is established, and the old process later returns. The design must preserve one valid history and reject stale authority at the resource it could damage. A timeout supplies suspicion, not proof that the old process has ceased acting.

The case connects failure detection, logical ordering, terms, durable voting, quorum decisions, fencing, membership, and client retry identity. It distinguishes preserving accepted state from making useful service available quickly after the transition.

Primary locations: Lessons 25, 27, 28, 29, 38, and 39.

A recoverable deletion and a torn write

A replicated valid deletion and a partially written page are different incidents. The first may need an independent historical recovery point; the second may need engine recovery information and integrity handling. A checksum can detect selected damage but is not a replacement copy.

The scenarios connect WAL, checkpoints, replay, backup consistency, encryption keys, restore time, and validation. They show why process startup, live replicas, and existing backup files are each insufficient evidence of a complete recovery capability.

Primary locations: Lessons 8, 19, 24, 39, and 42.

Reference-engine synthesis

Lesson 48 carries the mechanisms into a cumulative design. Its three workloads retain different requirements: the marketplace exposes contention, the tenant service offers independent ownership with skew, and the shared world exposes delivery and presentation costs. The lesson explains which engine boundaries can be reused and which must diverge.

The result is an architectural walkthrough rather than an implementation assignment. Every introduced transition is explained through its normal path, failure assumptions, and remaining resource costs. No reader action or external workbook is required.

Course index · Curriculum · References