Multiple-choice synthesis across the data-and-money cases: cardinality, exactly-once and watermarks, idempotency and the double-entry ledger, the lost update, exchange determinism, and the double-booking race.
SDCSenior◷ 13 min
Level
FoundationsJuniorMiddleSenior
Six questions that cut across the unit. Each is a decision you make in a design review where the output is money or correctness-critical data — not a definition to recite, but the reasoning that prevents a double-charge, a cardinality OOM, or a double-booking.
Confirm you can spot the cardinality bomb, separate exactly-once from late events, apply an idempotency key, defeat a lost update, justify a single-threaded exchange core, and prevent a double-booking.
Quiz
Completed
A metrics team adds a label `user_id` (millions of values) to a high-traffic metric. What breaks, and why?
Heads-up The sample RATE barely moves; what explodes is the ACTIVE-SERIES count (the product of label cardinalities), which sets the memory/index footprint. A faster write path doesn't help a cardinality blowup.
Heads-up A label isn't a column; it forks a whole new time series the DB tracks with index + memory overhead. A unique-per-user label means millions of series — the classic OOM, not 'a few bytes'.
Heads-up The binding constraint is MEMORY for active series (index + open chunks), not disk. Unbounded cardinality blows the in-memory index first; that's what kills the box.
Quiz
Completed
In ad-click aggregation, a click arrives 30 minutes late; its event-time window closed long ago. Exactly-once is enabled. Is it counted, and how do you still bill it?
Heads-up Exactly-once is about not double-applying; lateness is a windowing/watermark concern. A window that already closed won't admit it — the batch layer recovers it, not the exactly-once mechanism.
Heads-up That taxes EVERY result with 30 min of staleness to rescue a rare straggler. Size the watermark for the common case and let the batch layer (no time pressure) catch the tail.
Heads-up Aggregation is by EVENT time precisely so it doesn't land in the wrong minute. Its real window closed; the stream drops it and batch reconciliation recovers it.
Quiz
Completed
A client charges a card, the PSP succeeds, but the response is lost; the client retries. What prevents the double charge, and where must the key originate?
Heads-up If the response was lost, the client never received the server's ID, so the retry can't reuse it — it looks like a fresh payment. The key must come from the client before the first attempt.
Heads-up A local transaction can't span the external PSP call, and it doesn't help when the RESPONSE is lost after the PSP already charged. You need a client idempotency key to recognize the retry.
Heads-up Not retrying risks a genuinely-missed charge (the timeout is ambiguous). The correct move is to retry SAFELY with an idempotency key, so duplicates are recognized and missed charges still complete.
Quiz
Completed
Two concurrent debits ($70, $60) both read a $100 wallet balance, both pass their check, both write back, and the wallet overdraws. What is this and the cleanest single-wallet fix?
Heads-up Nothing deadlocks — both succeed, which is the bug. It's a lost update from a read-modify-write race. A retry loop doesn't close the read-write gap; an atomic conditional write (or a lock) does.
Heads-up It happens on a single primary — two concurrent transactions reading the same row before either writes. The fix is concurrency control (atomic conditional write / SELECT FOR UPDATE), not where you read.
Heads-up Even a strongly consistent store loses the update if the app reads-decides-writes with a gap. Make the decide-and-write atomic at the DB or hold a row lock — not merely change the consistency model.
Quiz
Completed
An exchange's matching core is single-threaded over a sequenced stream. An engineer proposes multiple matching threads 'to go faster.' Why is that wrong?
Heads-up For a matching book, concurrency destroys the single total order that fairness and audit require, and adds lock/cache contention. The core is deliberately single-threaded; you parallelize everything AROUND it.
Heads-up Locks reintroduce scheduling-dependent ordering (nondeterminism) and contention, defeating the purpose. A single thread over a sequenced stream needs no locks and stays deterministic.
Heads-up It's the MATCHING core that must be single-threaded for a deterministic total order; the log is appended in that same order. Parallel matching breaks determinism regardless of the log.
Quiz
Completed
Two guests book the last room for the same night within a second; both saw '1 available' and both got confirmations. What is this, and the correct fix for a multi-night stay?
Heads-up Even a perfectly fresh read lets two requests see '1' before either writes. The guarantee belongs at the atomic check-and-reserve; search may be slightly stale and advisory.
Heads-up Per-night updates must be ALL-OR-NOTHING in one transaction, or a 3-night stay books 2 nights then fails on the 3rd. And without atomicity per night you still have the race.
Heads-up Search is ~100× the traffic; forcing it strongly consistent kills scalability and STILL can't guarantee the room (someone books between search and click). The guarantee is the atomic reserve.
Recall before you leave
01
Why is exactly-once not the answer to a late event?
02
What's the common thread between the lost update and the double-booking?
Recap
The unit’s hazards are a named checklist you run in any design review where the output is money or correctness-critical data. The cardinality bomb: series count is the product of label cardinalities, so an unbounded label OOMs the TSDB — keep labels bounded. Exactly-once vs lateness: exactly-once stops double-applying, not late events, which a watermark sizes for and batch reconciliation recovers. The idempotency key: client-minted, atomic check-and-store, so a retry after a lost response returns the original result instead of charging twice. The lost update and the double-booking are the same read-modify-write race — fixed by making check-and-act one atomic operation (per balance, or per night all-or-nothing). And exchange determinism: a single sequenced total order through a single-threaded core, so replicas and replay agree — never parallelize one book. Each hazard has a precise, atomic fix, and recognizing which one you’re facing is the senior skill this unit builds.