Section 5: One Truth, Many Copies - Data Modeling

Executive Summary: We split the data in two: PlaceDB, the transactional source of truth keyed by place_id, and the search index, a denormalized copy that can be rebuilt and is shaped for Section 4's search contract. We define the places and place_sources tables, then the index document with its p4–p7 geohash tokens, precomputed Bayesian rating and encoded opening hours. Then we key every store and cache.

The interviewer taps the API from Section 4: "You've promised search and details. What's actually stored behind them?" Lead with what many candidates miss: those two endpoints shouldn't read the same data.

Two Stores, Two Jobs

Details must be correct. When an owner fixes their phone number, the page must show it, and two edits that race must not corrupt the record. Search must be fast. Sam's "ramen" query has to turn 23,600 places in 12 cells into 20 ranked results within the 70 ms index budget. So we keep one source of truth and make everything else a copy built from it.

Key Insight: The index is derived and disposable. We can rebuild it from a PlaceDB snapshot at 50K docs/s, about 67 minutes for 200M places. A corrupted index or a bad mapping costs a rebuild. Only a corrupted PlaceDB is a real disaster, which is why only PlaceDB gets point-in-time recovery (Section 11).