Quick Answer
How to design Yelp nearby search 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 System Design interview English hub.
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.
Technical Software Interview English knowledge base
← Technical Software Interview English knowledge base - start at How to Walk System Design Interviews in English for the full chapter index and reading order.
Explore every Mockly article on the blog hub.
All chapters in this series
Jump between Technical Software Interview English posts below. Each chapter builds spoken English for the same book - use the KB overview when you want the big picture.
| # | Chapter | Slug |
|---|---|---|
| 1 | How to Walk System Design Interviews in English | system-design-interview-seven-steps-in-english |
| 2 | How to Design Pastebin in English Interviews | pastebin-system-design-in-english |
| 3 | How to Design Instagram in English Interviews | instagram-system-design-in-english |
| 4 | How to Design Twitter Timeline in English | twitter-system-design-in-english |
| 5 | How to Design Yelp Nearby Search in English (you are here) | yelp-nearby-system-design-in-english |
| 6 | How to Design Uber Dispatch in English | uber-system-design-in-english |
| 7 | How to Design Ticketmaster in English | ticketmaster-system-design-in-english |
| 8 | Long Polling vs WebSockets vs SSE in English | long-polling-websockets-sse-in-english |
- How to Walk System Design Interviews in English
- How to Design Pastebin in English Interviews
- How to Design Instagram in English Interviews
- How to Design Twitter Timeline in English
- How to Design Yelp Nearby Search in English - you are here
- How to Design Uber Dispatch in English
- How to Design Ticketmaster in English
- Long Polling vs WebSockets vs SSE in English
FAQ
Questions
More questions? Email us at contact@mocklyenglish.com.