Read real limiter code, an ID config, a bloom-filter sizing call, and a geohash query, then pick the answer a senior engineer would commit to: the lost-update race, the index-fragmenting key, the saturated filter, and the missed boundary neighbour.
SDSenior◷ 14 min
Level
FoundationsJuniorMiddleSenior
Building-block bugs hide in the code, not the prose: a read-then-write that isn’t atomic, a primary key that fragments the index, a filter sized for the wrong N, a query that forgets the neighbour cells. Read each snippet, find the flaw, and pick the fix a senior engineer would commit to.
Practise the review loop you run on real building-block code: locate the operation, check whether it’s atomic / time-ordered / correctly sized / boundary-aware, and choose the change the mechanism actually requires.
Snippet 1 — the limiter increment
def allow(key, limit): n = redis.get(key) or 0 # read if int(n) < limit: redis.set(key, int(n) + 1) # modify-write (separate op) return True return False
Quiz
Completed
This limiter runs on many servers against one Redis. Under concurrency, what bug does the read-then-write introduce, and what's the fix?
Heads-up Redis serializes individual commands, but GET and SET here are SEPARATE commands with a gap between them. Two requests can both GET the same value before either SETs. You need a single atomic INCR (or Lua), not two ops.
Heads-up The int() conversion is fine. The real bug is that the read and the write are two non-atomic operations, so concurrent requests race into a lost update. Use atomic INCR.
Heads-up It OVER-counts the client (lets too many through): concurrent requests both see a stale low n and both allow. The fix for the lost update is an atomic increment-and-check.
Snippet 2 — the primary key
-- high-volume events table, InnoDB (clustered PK)CREATE TABLE events ( id UUID DEFAULT gen_random_uuid() PRIMARY KEY, -- random UUIDv4 body JSONB, ts TIMESTAMPTZ);
Quiz
Completed
At millions of inserts/hour, this clustered random-UUID primary key hurts. What's the problem and the minimal change?
Heads-up Width is secondary. The throughput hit is fragmentation from RANDOM keys on a clustered index. A time-ordered UUIDv7 keeps the UUID benefits while restoring right-edge inserts.
Heads-up Generation cost is negligible next to the index fragmentation random keys cause. Use UUIDv7 (time-ordered) to fix the insert pattern, not to speed up generation.
Heads-up On a clustered index, spreading inserts across the whole tree is BAD: it causes page splits and destroys cache locality. You want sequential right-edge inserts, which a time-ordered UUIDv7 provides.
Snippet 3 — the bloom filter sizing
# sized once at startupbf = BloomFilter(expected_items=1_000, fp_rate=0.01)# ...later, in production, it ingests every event keyfor key in stream: # millions of keys over time bf.add(key)
Quiz
Completed
The filter was sized for 1,000 items but ingests millions. What happens, and what stays guaranteed?
Heads-up Saturation never causes false negatives — that guarantee is structural (adding only sets bits). It causes the false-POSITIVE rate to climb toward 100%, making the filter useless but never wrong about 'definitely absent.'
Heads-up A plain bloom filter can't resize. Past its sized N it saturates and the false-positive rate climbs. You must rebuild a larger one (or use a scalable bloom filter that chains larger filters).
Heads-up The 1% holds only at the sized N. Insert 1000× more and the array saturates, pushing the false-positive rate toward 100%. Size for the real N.
Snippet 4 — the proximity query
def nearby(lat, lng): cell = geohash_encode(lat, lng, precision=6) # ~1 km cell return db.query( "SELECT * FROM drivers WHERE geohash LIKE %s", cell + '%' ) # only the rider's own cell
Quiz
Completed
This returns no driver even when one is parked just across the street. What's wrong and what's the fix?
Heads-up Precision doesn't fix the boundary: a driver across ANY cell edge still has a different prefix. The fix is to expand the query to the 8 neighbour cells (3×3 grid), not change precision.
Heads-up A prefix LIKE ('cell%') uses a string/B-tree index fine — that's geohash's whole point. The bug is querying only one cell; include the 8 neighbours.
Heads-up Exact-distance ranking is needed too, but the missed-neighbour bug is the boundary problem: a single-cell query can't see a driver across the edge. You must add the 8 neighbour cells first, then rank by distance.
Recall before you leave
01
How do you spot and fix the distributed-limiter race in code?
02
Why does a random-UUID clustered primary key hurt insert throughput, and the minimal fix?
03
What happens when a bloom filter is sized for too few items, and what's preserved?
Recap
Every building-block decision in this unit can be read straight off the code. A limiter that does a separate read then write across a fleet has a lost-update race — collapse it to an atomic INCR or Lua script. A random-UUID clustered primary key fragments the B-tree at high insert rates — switch to a time-ordered UUIDv7 for right-edge inserts. A bloom filter sized for too few items saturates (false-positive rate → 100%, but never false negatives) — rebuild for the true N. And a geohash proximity query that scans only the rider’s cell hits the boundary problem — include the 8 neighbour cells, then rank by exact distance. The senior habit is the same each time: find the operation, name the invariant it must hold (atomic / time-ordered / correctly sized / boundary-aware), and choose the fix that restores it.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.