Quick Answer
Yelp nearby system design in English: clarify radius search and ranking, estimate locations and QPS, then narrate geo-hashes or quad trees and why SQL alone is too slow.
Diagrams and what to say while drawing
Draw as you speak: requirements → APIs → estimates → boxes → deep dive → bottlenecks. Western panels score the narration as much as the diagram.
Key vocabulary
| Term | Plain meaning | Say it in an interview |
|---|---|---|
| Quad tree | Spatial index tree | “I’d index places with a quad tree.” |
| Geohash | Encode lat/long as a string | “Geohashes make nearby queries cheaper.” |
| Radius search | Find places within X km | “We need efficient radius queries.” |
| Ranking | Order by distance/relevance | “I’d rank by distance and rating.” |
ESL English phrases and transitions
Open and clarify
- “I’ll clarify search radius, result limit, and freshness of locations.”
- “Plain SQL distance scans won’t scale — I’ll propose a geo index.”
- “Reads dominate; writes are location updates and new places.”
UK/US system design moves
- “The tradeoff is X versus Y.”
- “I’ll deep-dive this component next.”
- “A single point of failure here would be …”
Pair this chapter with Mockly’s related article: how to explain scaling from zero to millions in english.
Key English language pitfalls
| Pitfall | Sounds like | Say instead |
|---|---|---|
| Ignoring earth geometry | Wrong distances | Mention approx + refine. |
| One global quad tree | Hot regions | Partition by city/region. |
| No ranking talk | Poor UX | Distance + rating + availability. |
| Summary | Clear tradeoffs are how Western panels hear senior engineers. | |
Common English mistakes
| Mistake | Why it hurts | Fix |
|---|---|---|
| Jumping to ML recommendations | Off-ask | Solve nearby search first. |
| Forgetting load spikes | Events/concerts | Call out hot downtown grids. |
| Silent index choice | Weak | Compare quad tree vs geohash briefly. |
What the interviewer is testing
For geo / nearby search design, UK/US interviewers test structured thinking, scale intuition, and calm spoken English — not accent perfection.
They listen for clarify → estimate → design → tradeoffs → bottlenecks. If those moves are audible, you sound hireable.
How to open in English
First 20 seconds
- “I’ll clarify search radius, result limit, and freshness of locations.”
- “Plain SQL distance scans won’t scale — I’ll propose a geo index.”
- “Reads dominate; writes are location updates and new places.”
yelp nearby friends system design
Use this sequence for yelp nearby friends system design. Say the step name before you do it.
| Step | What to say |
|---|---|
| Clarify | People vs businesses; radius; filters; mobile update rate. |
| Estimate | Places, users, QPS for nearby queries. |
| Why not naive SQL | Full scans are too slow at scale. |
| Index | Quad tree or geohash grids; shard by region. |
| API + cache | nearby(lat, long, radius); cache popular downtown queries. |
Weak vs strong answers
Weak
I’d SELECT * FROM places and filter in the app.
Strong
I’d index locations with geohashes, query neighbouring cells, refine by exact distance, and cache hot downtown queries — then shard by region.
How to say the key terms
| Term | Say it |
|---|---|
| lat/long | “latitude and longitude” |
| radius km | “within five kilometres” |
Follow-up questions you will get
Expect these
- “How do you update a driver’s location every few seconds?”
- “What if the densest cell is Manhattan at lunch?”
Practice drill
Set a timer for twelve minutes. Design geo / nearby search design out loud in English. Record yourself. Check: clarify, estimate, tradeoffs, bottlenecks.
Repeat tomorrow focusing only on the deep-dive section.
Answer frameworks you can reuse
Clarify → APIs → Estimates → Data model → High-level → Deep dive → Bottlenecks.
For every deep dive: options → tradeoffs → recommendation.
Frequently Asked Questions
Tap a question to expand the answer.