Section 12: The Follow-Ups That Test the Foundations - Interviewer Challenges: Privacy, Abuse, Cost & Evolution

Executive Summary: The design is drawn and defended, so the interviewer turns adversarial. We answer six challenges in the same three beats: what they're really asking, the answer, the senior line. They are location data in logs, a competitor scraping the catalog, a 30% cost cut, New Year's Eve in Times Square, search along a route, and personalized ranking. None needs a rebuild, because every answer reuses the cell as the unit of indexing, caching and sharding.

The interviewer puts the marker down: "Okay, it works. Now let's see if it survives."

Challenge 1: "Your logs know where everyone eats lunch."

What they're really asking: Do you treat location as personal data with a lifecycle, or as just another column?

The answer: Raw coordinates never reach disk (D10). Sam's 40.7536, −73.9832 exists only in the memory of the request that ranks their ramen results. The gateway scrubs it before anything is written:

The logs keep geohash5, a cell about 3.7 × 4.9 km at New York's latitude: enough to plan capacity for "Midtown at lunch", far too coarse to place Sam on a bench. The result cache key, (dr5ru6, "ramen", open_now, relevance), holds no user id, so a cache dump doesn't say who searched. Raw logs (about 4.5 TB over the 30-day window) are encrypted, then deleted. Analytics drops any cell with fewer than 20 distinct users, because a coarse cell with one person in it at 3 a.m. still identifies someone.

Critical Insight: Someone will propose keeping raw lat/lng "for ML later". That is the rejected alternative: data you never stored can't leak, be subpoenaed or be misused. If a user opts in to location history, it goes to a separate consented store with its own retention, and it never becomes the default.

The senior line: "Precision is a cost. Every system that touches location gets the coarsest cell that still does its job."

Quick check before moving on: