This article dives into the hidden failures that crop up when your database leaves the ideal “happy path.” It covers contention, slow queries, race conditions, stale reads, retries and live migrations, and shows how production realities can break simple transactional code.

• A slow query isn't just "slow" — threads sitting idle in transactions hold locks and connections until the pool fills up and unrelated requests start timing out.
• Client-side timeouts and retries can pile new connections onto a backlog while the original transaction still commits, causing duplicate orders or inconsistent stock.
• Concurrent "check stock" calls can each see available inventory and decrement it in parallel, leading to overselling.
• Replica lag and mixed old/new code during schema migrations can silently feed stale reads or trigger deadlocks in production.

This course covers core concepts of concurrency control—threads, locks, transactions, and crash recovery—in the first half, then shifts to distributed systems topics like network models, clocks, replication, consensus, and fault tolerance. It lists lecture topics, objectives, prerequisites, and recommended readings for a Part IB CST Michaelmas module led by Dr. Martin Kleppmann.

• Kleppmann's 16-lecture Part IB course splits evenly: 8 lectures on concurrency control, 8 on distributed systems.
• The concurrency half moves from basic threads/locks through bakery algorithm, semaphores, monitors, and message-passing (actors, CSP) to ACID transactions, 2PL, optimistic concurrency, and crash recovery.
• The distributed half covers network/failure models, physical and logical clocks, replication and consensus (Raft, FLP impossibility, 2PC, CAP), ending with case studies on CRDTs and Google Spanner's TrueTime.
• Core texts backing the course are Tanenbaum's Modern Operating Systems, Goetz's Java Concurrency in Practice, and Kleppmann's own Designing Data-Intensive Applications.

Maintaining consistency in a system comprised of separate databases can be challenging, particularly in the absence of transactions. The article discusses the importance of defining a system of record versus a system of reference and emphasizes the Write Last, Read First principle to ensure safety properties like consistency and traceability in financial transactions.

• Write to the system of record last, but read from it first — this ordering prevents referencing data that hasn't actually been durably committed.
• If a downstream write (e.g., to a search index or cache) fails after the system of record succeeds, that's recoverable via retries; failing in the other order risks phantom reads of uncommitted state.
• Treating one database as the authoritative system of record (vs. other systems of reference) gives you a clear conflict-resolution and recovery strategy when multiple stores disagree.