Data & money: free-recall review
Free-recall prompts across the data-and-money cases. Reconstruct each design from memory — cardinality, exactly-once and reconciliation, idempotency and the ledger, the lost update, exchange determinism, double-booking — then reveal and compare.
Retrieval beats re-reading. For each prompt, reconstruct a full answer from memory — the mechanism and the fix — before you open the model answer. The effort of rebuilding is what makes the cardinality rule, exactly-once, and the lost-update fix stick.
Reconstruct each case’s core decision without looking back: what kills a metrics DB, what exactly-once does and doesn’t cover, how an idempotency key and a double-entry ledger keep money correct, how to defeat the lost update, why an exchange is single-threaded, and how to prevent a double-booking.
- 01What kills a metrics database, and how do you keep it alive?
- 02What does exactly-once cover in ad-click aggregation, and what handles the rest?
- 03How do an idempotency key and a double-entry ledger keep a payment correct?
- 04What is the lost update, and what's the single common fix shared with double-booking?
- 05Why is a stock exchange single-threaded, and how does that give recovery and audit?
If you could reconstruct each answer from memory, you hold the unit’s spine. Cardinality (the product of label cardinalities) kills a metrics DB, so keep labels bounded. Exactly-once is at-least-once + idempotent/transactional application and covers only the engine’s internal state — late events are a watermark concern recovered by batch reconciliation (lambda). A client idempotency key with atomic check-and-store stops the double charge, and an append-only double-entry ledger keeps money conserved, immutable, and auditable. The lost update and the double-booking are the same read-modify-write race, fixed by one atomic check-and-act (per balance, or per night all-or-nothing). And an exchange is single-threaded over a sequenced total order so a deterministic core makes the log enough for recovery, replicas, and audit. The thread tying them together: when the output is money or correctness-critical data, you reason in named hazards and apply precise, atomic fixes — before production teaches them to you.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.