Multiple-choice synthesis across the building-blocks unit: the rate-limiter race, time-ordered vs random IDs, the bloom filter's one-sided guarantee, the geohash boundary problem, and the split-brain that fencing tokens defeat.
SDSenior◷ 13 min
Level
FoundationsJuniorMiddleSenior
Five questions that cut across the whole unit. Each is a decision you make when you reach for an off-the-shelf mechanism — a limiter, an ID scheme, a membership filter, a spatial index, a coordinator — and get the subtle part right instead of the obvious part.
Confirm you can spot the distributed-counter race, pick a time-ordered vs random ID for the situation, reason from the bloom filter’s no-false-negatives guarantee, defeat the geohash boundary problem, and make split-brain harmless with a fencing token.
Quiz
Completed
A rate limiter runs on 40 servers, each doing GET-counter → check < limit → SET counter+1 against shared Redis. Clients exceed their limit under load. What's the minimal correct fix?
Heads-up Static splits waste capacity under uneven balancing and still drift. The bug is the read-modify-write race on the shared counter; the fix is an atomic increment-and-check, not partitioning the limit.
Heads-up A per-request lock serialises the whole fleet and becomes the bottleneck. You need an atomic primitive (INCR/Lua), which gives correctness without serialising every request.
Heads-up That hides the bug instead of fixing it and defeats the limiter's purpose. The overshoot is a lost-update race; close it with atomicity.
Quiz
Completed
A clustered-index OLTP table ingests millions of rows/hour and you need decentralized ID generation across regions without fragmenting the index. Which ID scheme fits best?
Heads-up A central sequence is a write-path bottleneck and SPOF — the opposite of decentralized. Use a coordination-free, time-ordered ID so each region mints its own without fragmenting the index.
Heads-up UUIDv4 is decentralized but its randomness fragments a clustered B-tree (page splits, lost cache locality), which is exactly the throughput problem you're trying to avoid. UUIDv7 keeps decentralization AND right-edge inserts.
Heads-up Local counters collide across shards (two shards both emit id 1), so IDs aren't globally unique. A time-ordered distributed ID avoids both the collision and the fragmentation.
Quiz
Completed
You want to guard an expensive database read with a bloom filter, but a teammate worries a wrong answer could cause harm. When is the filter safe to use here?
Heads-up Bloom filters have NO false negatives — 'definitely absent' is always correct. The only error is a false positive (a harmless extra lookup). That's exactly why they're safe as a read guard.
Heads-up Deletion is irrelevant to read-guard safety (and a plain filter can't delete anyway). Safety comes from the one-sided guarantee: a false positive only causes a harmless fallback read.
Heads-up They're safe wherever a false positive is cheap (a fallback to ground truth). They're only unsafe as the SOLE authority for a harmful 'yes' — a read guard is the safe case.
Quiz
Completed
A 'drivers near me' query selects only the rider's own geohash cell and misses a driver parked 20 m away across the street. What's the fix?
Heads-up Precision doesn't fix it — a driver just across ANY cell boundary still has a different code. The boundary problem is solved by expanding to the 8 neighbour cells, not by changing precision.
Heads-up An ordinary string/B-tree index handles geohash prefix scans fine. The bug is querying one cell; the fix is including the 8 neighbours, regardless of index type.
Heads-up That throws away the whole point of geohashing (an indexed prefix scan). Keep the index; just expand to the rider's cell plus its 8 neighbours and then rank by exact distance.
Quiz
Completed
A leader takes a lock, suffers a long GC pause past its lease, a new leader is elected, and the old one wakes up still acting as leader. Both write. What actually prevents corruption?
Heads-up No timeout distinguishes 'dead' from 'frozen,' and a longer lease only slows failover while still allowing arbitrarily long pauses. The real fix is a fencing token enforced at the resource.
Heads-up More nodes don't stop a stale leader from acting after its lease expired. The fix is fencing tokens so the resource rejects stale-token operations.
Heads-up It acts before it notices; that's the danger. You must fence its stale writes at the resource with a monotonically increasing token, not trust it to self-correct.
Recall before you leave
01
Why does a distributed rate limiter overshoot, and what's the one-line fix?
02
When is a bloom filter safe, and when is it not?
03
State the fencing-token rule that defeats split-brain.
Recap
The through-line of the unit is that each building block has an obvious surface and a subtle correctness core. A rate limiter is trivial on one node but races on a fleet — the fix is an atomic increment-and-check on one shared counter (and fail open if it’s down). ID generation is trivial with one writer but needs a time-ordered scheme (Snowflake/UUIDv7) to stay coordination-free without fragmenting the index. A bloom filter is a fast membership pre-check that is safe only where a false positive is cheap, because it guarantees no false negatives but not no false positives. Geohashing turns proximity into a prefix scan but must query the cell plus its 8 neighbours to beat the boundary problem. And leader election is easy until split-brain, which no timeout can prevent — only a fencing token enforced at the resource makes a stale leader harmless. Get the subtle part, not just the obvious part.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.