How the interviewer opens it
“Design a service that finds nearby places within a radius or a map viewport. It must support low-latency searches over millions of places.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Scale and distribution
- Read and write mix
- Search shapes and distance
- Result order and size
- Place fields and filters
- Latency and supported failures
- Freshness and availability
- Change source and durability
- Record sizes
- Scope limits
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Find places within a radius or a map viewport
- Return the nearest places, with an optional category filter
- Apply place additions, changes, and deletions
Usually out of scope
- Text search
- Routes and travel times
- Reviews and personal scores
- The source of place data
What interviewers ask about
- Search boundaries
- Longitude wraps at the map edge. Distance and viewport rules must also remain correct near the poles.
- Search work in dense areas
- One city query can cover hundreds of thousands of places. A small result limit does not guarantee little database work.
- Place changes
- A coordinate change affects both the old and new search areas. Repeated or delayed changes can restore obsolete data.
Common mistakes
- Use latitude and longitude differences as distance without a geographic distance calculation.
- Return every place from intersecting cells without an exact shape check.
- Search a fixed number of adjacent cells for every radius.
- Apply the result limit before the category and shape checks.
- Add geographic shards before a capacity estimate shows that one indexed database cannot meet demand.
- Accept old place changes without a version rule.
The bar by level
- Mid-level (L4/E4)
- Defines both search APIs and a usable place model. Uses a spatial index, exact shape checks, and correct distance order. Estimates read load and storage.
- Senior (L5/E5)
- Tests query plans for dense areas and rare categories. Handles longitude boundaries, versioned changes, replica lag, and durable changes after node failure.
- Staff (L6+/E6+)
- Proves that distance pruning preserves the nearest results. Defines a combined freshness budget and tests capacity after failures. Plans geographic partitions only when growth requires them.