Building Software
Engineering Fundamentals for the Agent Era
A read-modify-write on a balance or counter with no transaction or lock, losing updates under concurrent requests.
A multi-step change where a failure halfway through leaves partial data behind.
A read from a replica right after a write to the primary, so users don't see their own change.
An assumption that the database's default isolation level prevents double-booking when it does not.
Making multi-step changes all-or-nothing, and understanding what concurrent readers and writers can see.
An agent wrote a gift-card redemption endpoint that reads the balance, checks that it covers the purchase, and writes the new balance in three separate statements. Find the concurrent sequence that spends the same balance twice, and write the test that reproduces it.
Watch
Unpacks what ACID actually guarantees and shows that common default isolation levels still allow lost updates and write skew, with the double-booking style examples this subsection is about.
Uses Jepsen's test results to define isolation anomalies precisely and shows real databases violating the isolation levels they advertise.
Defines strong consistency as linearizability and shows how a read from a lagging replica after a write breaks it, which is the stale-read bug behind replica reads.
Its transactions and replication chapters define dirty reads, lost updates, write skew and phantoms, which isolation levels stop each one, and how to provide read-your-writes on top of replica lag.
Explains transaction processing, recovery logs, locking and optimistic concurrency control, then replication and consistency models, from the storage engine up.
Manual
The table of which anomalies each isolation level allows in PostgreSQL, and the serialization failures an application must retry under Repeatable Read and Serializable.
Reference
A map of consistency models from serializable and linearizable down to read-your-writes, each with a short definition of what it promises.