Section 11: Same Two Numbers, New Questions - Follow-up Feature Evolution

Executive Summary: The adversarial phase is over and the interviewer turns generative: product wants geo filters, live notifications, an audit trail, new tenants, privacy erasure and dashboard curves. Each one attaches to the existing design as a column, a consumer, a key or a config row, with what changes, what stays, the cost, the rejected alternative and the flip trigger. The interval index (Sections 5 and 7) and the live-edge contract (Section 8) survive all of them, with at most a type prefix on the key.

The interviewer leans back. "Safety ops loves it. Now everyone wants something. How does this grow?"

Two answers lose here: rebuilding the bucket store for each request, or revealing it was all built on day one, which makes Section 2's out-of-scope list theater. The winning answer names, for each feature, the seam it plugs into before drawing anything.

Geo Filter: Rides Active Inside a Polygon

Interviewer: "The water main is on Market Street. Safety ops doesn't want all 25,000 SF rides from 17:10 to 17:40. They want the ones near the break."

You: "First, one question: 'near' meaning the ride started inside the polygon, or passed through it? Pickup location is one point we already know. Passing through needs the route, which is a much bigger feature."

Interviewer: "Pickup is fine for now."

So each row gains two things: the pickup's H3 cell at resolution 7 (Uber's open-source hexagonal grid, where a cell averages about 5 km²) and the exact pickup lat/lng. A polygon drawn around Market Street gets converted into a covering set of res-7 cells: either an overlap-containment polyfill mode, or the default centroid-based polyfill plus a one-ring buffer. The default alone keeps only cells whose centre lies inside the polygon, so it would drop pickups near the edge, and a street-scale polygon, smaller than one cell, can come back as zero cells. The query reads the same city buckets it always did, keeps rows whose cell is in the cover, then runs an exact point-in-polygon test that removes the false positives the cover lets in.

What changes: two payload columns in events_by_id, events_by_bucket and the ev:{city_id}:{event_id} hash (for example ev:{sf}:trip_8f3a), plus one filter stage. What does not change: the partition key (city_id, bucket_start), the emit rule, the overscan math, the cursor.

The rejected alternative is a partition variant keyed (city_id, bucket_start, h3_parent). It would split every city-wide query across many more partitions, and city-wide is the dominant query. Flip trigger: geo-filtered reads become a large share of load and polygons usually cover a small slice of the city. Then that variant becomes a second table, roughly doubling bucket writes from about 2,000/s to about 4,000/s at peak and adding about 14 GB/day of storage.

Quick check before moving on: