5
State: Data, Concurrency and Distribution
The hardest bugs live where data is stored, shared or spread across machines.
Why it matters when agents do the typing
Lost updates, duplicate charges, stale reads and unrecoverable data rarely show up in a demo or a single-user test. They show up under real concurrency, real network failures and real data volumes, where the people who own the system get paged and the users get hurt. Understanding transactions, races and partial failure is how you find these bugs before your users do.
-
Core 8
Depth: do
Data Modeling and Databases
Designing schemas, keys and constraints, choosing the right kind of store, and understanding how a database finds data quickly.
A mistake it teaches you to catch: Lists stored as comma-separated strings or opaque JSON blobs, making queries slow and integrity impossible to enforce.
-
Core 9
Depth: do
Transactions and Consistency
Making multi-step changes all-or-nothing, and understanding what concurrent readers and writers can see.
A mistake it teaches you to catch: A read-modify-write on a balance or counter with no transaction or lock, losing updates under concurrent requests.
-
Depth: explain
Concurrency and Race Conditions
What goes wrong when many things happen at once, within one process or across many workers: races, deadlocks and overload.
A mistake it teaches you to catch: Check-then-act races, such as checking stock and then decrementing it in two separate steps.
-
Core 10
Depth: do
Distributed Systems and Partial Failure
When work spans machines, any step can fail, stall or happen twice, and the design has to assume it will.
A mistake it teaches you to catch: Retries without idempotency that charge a customer twice when the first attempt had actually succeeded.