Proximity Service (Yelp) — System Design Interview

Phase 1: Clarify, Scope & Constraints

---

Interviewer: "Let's design a proximity service — like Yelp. Users want to find nearby businesses. How do you approach this?"

Candidate: "Great. Let me clarify the core user journeys:

1. Search journey — User searches for businesses near a location ('pizza near me', 'coffee shops within 1 km')
2. Browse journey — User browses categories of businesses in a geographic area
3. View journey — User views a specific business profile (hours, reviews, photos, location)
4. Add/update journey — Business owner adds or updates their listing

The dominant complexity is geospatial search. Standard database queries (WHERE city = 'NYC') don't work for 'find all restaurants within 5 km of my current location' — you need a specialized spatial index. The challenge is doing this efficiently at scale across millions of businesses globally.

WHY: The secondary complexity is the read/write ratio. Business data changes infrequently (a restaurant's location, hours, or menu updates maybe once a week), but searches happen constantly. This is an extremely read-heavy workload, which means we can aggressively cache and pre-index data.

Non-goals for V1:

• Reviews and ratings (separate write-heavy user content system)
• Photo upload and storage
• Real-time data (current wait times, live inventory)
• Reservations and booking
• Ads and sponsored listings

Interviewer: "What makes this problem interesting beyond just a database query?"

Candidate: "Standard SQL can't efficiently answer 'find all points within R km of point P'. If you try WHERE lat BETWEEN ? AND ? AND lng BETWEEN ? AND ? — that's a two-column scan with no spatial index. The Earth…