System Design Interview: Proximity Service (Like Yelp) Experience
Interview Experience
Functional Requirements *
Search: Users can search for nearby places (restaurants, gyms, events) or people based on current location. *
Filtering: Support for filters including distance, c
Full Details
Functional Requirements *
Search: Users can search for nearby places (restaurants, gyms, events) or people based on current location. *
Filtering: Support for filters including distance, category, ratings, open status, and personalized recommendations. *
Place Details: Users can view business information, photos, reviews, and ratings. *
Management: Business owners can add, edit, or claim listings; users can add reviews. *
Bookmarks: Users can save favorite locations.
Non-functional Requirements *
Latency: Millisecond-level search responses. *
Scalability: Support for millions of users and tens of millions of locations. *
Availability: High availability (99.99% uptime). *
Consistency: Eventual consistency is acceptable for new locations, updates, and reviews.
Capacity Estimation *
Traffic: 50M MAU, 10M DAU. Average 5 searches/user/day. Peak QPS ~100,000. *
Volume: 5M reviews/day, 100k new places/day. *
Storage: * 100M listings (~200 GB total). * 1B historical reviews (~1 TB total). * Photos (5 per business) (~100 TB total). * 100M favorites (~5 GB total).
API Design * GET /search?lat&lon&radius&category&open_now:
Returns sorted list of nearby locations. * GET /place/:id: Retrieves specific place details. * POST /review/:placeId/add: Submits a new review. * POST /place/add: Business owners list a new location (name, coordinates, category, photos). * PUT /place/:id/edit: Updates listing details. * POST /place/:id/claim: Verifies ownership of an existing listing.
High-Level Architecture *
Client: Mobile/Web interfaces for searching and management. *
API Gateway: Handles auth, routing, throttling, and monitoring. *
Cache: In-memory storage for hot searches and trending zones. *
Load Balancer: Distributes traffic to app servers. *
App Servers: Business logic for listings, reviews, and search coordination. *
Message Queue (Kafka/Redis): Asynchronous processing for search index updates. *
Database: Persistent storage for user profiles and business data. *
Media Storage: Blob storage/CDN for images. *
Segments Producer: Ingests third-party map data (e.g., Google Maps) and divides the world into segments to narrow search scope. *
QuadTree Servers: Stores spatial indexes of places; finds locations within a radius. *
Aggregators: Collects results from QuadTree servers, ranks them, and returns the final list to the user.
Workflows
Flow-1: Business Listing 1. Owner submits details via /place/add. 2. Listing Service validates data and stores geo-indexed location. 3. Media Service links uploaded photos to the place. 4. Admin Service reviews/approves the listing. 5. Listing becomes searchable upon approval.
Flow-2: Proximity Search 1. User requests /search. 2. Gateway routes to Geospatial Search Service. 3. Search Service queries QuadTree servers for places within the radius. 4. QuadTree servers return candidates to Aggregators. 5. Aggregators filter, rank (proximity + popularity), and return results with metadata.
Flow-3: Review Submission 1. User posts to /review/:placeId/add. 2. Review Service validates, stores review, and updates average rating. 3. Review is displayed after moderation (if flagged).
Flow-4: Media Handling 1. Uploads are stored in object storage via Media Service. 2. Read requests fetch media URLs served via CDN.
**Component
Deep Dive Searching Strategy**
SQL Solution * Stores latitude/longitude in indexed columns. * Uses range queries to find points within a coordinate box. *
Limitation: Inefficient at scale (e.g., 500M places). Independent indexes on lat/lon result in large candidate sets requiring costly intersection operations.
Static Grids * Map is divided into fixed-size grids; each place has a GridID. * Queries search the target grid and its 8 neighbors. *
Limitation: Static grid sizes handle uneven data distribution poorly. Dense areas (e.g., NYC) overload a single grid, while sparse areas (e.g., Pacific Ocean) waste resources.
Dynamic Grids (QuadTree) * A tree structure where each node represents a spatial region. * Nodes subdivide into four quadrants when the number of places exceeds a threshold (e.g., 500). *
Mechanism: *
Leaf Nodes: Hold specific lists of places. *
Root: Covers the whole world. *
Traversal: Search navigates down the tree to the leaf node covering the user's location. *
Neighbors: Leaf nodes are connected via a doubly linked list, allowing expansion of the search radius to neighboring grids without re-traversing the root. *
Memory Efficiency: * 500M places * 12 bytes (ID + coords) ≈ 12 GB. * 1M leaf nodes (500 places per leaf) + internal nodes ≈ negligible overhead. * The entire index fits in the RAM of a modern server (~12 GB).
Ranking Search Results *
Popularity Score: Aggregated from ratings (stored in DB and cached in QuadTree nodes). *
Execution: QuadTree leaf nodes return the top 100 places sorted by popularity within the spatial radius. *
Aggregation: The central aggregator merges lists from relevant leaf nodes to form the final result. *
Updates: Popularity scores in the QuadTree are updated via batch processing (off-peak) to prevent locking and performance degradation during high-traffic reads.
Replication and Fault Tolerance *
Master-Slave Architecture: Writes go to the Master; Reads are distributed to Slaves. Eventual consistency applies. *
Failover: If the Master fails, a Slave is promoted. *
Rebuilding (Reverse Index): * If a QuadTree server fails entirely, rebuilding by scanning the whole DB is too slow. *
Solution: A separate "QuadTree Index Server" maintains a reverse index (ServerID -> Set of PlaceIDs). * When a server is replaced, it queries the Index Server to know exactly which places to load from the DB.
Data Partitioning *
Region-Based Sharding: * Places grouped by zip code/geography. * Pros: Preserves spatial locality. * Cons: Hotspots (e.g., downtown areas) cause uneven server load. *
LocationID Sharding (Hash-Based): * Places distributed uniformly based on hash of LocationID. * Pros: Even load distribution. * Cons: Every search query must be broadcast to all shard servers to find nearby places, increasing network traffic and latency. *
Conclusion: Region-based sharding is generally preferred, using consistent hashing or re-partitioning to handle hotspots.
About This Question
This is a candidate experience report from a yelp interview for a swe role during the system design round reported in 2025.
It covers the following topics: Sql, Binary Tree, Linked List, Sorting, System Design, Queue, Probability Stats, Matrix, Stack .
About Yelp Interview Reports
This question was reported by a candidate who interviewed at Yelp. LeakCode aggregates interview reports from 10+ sources, including 1Point3Acres, Glassdoor, LeetCode Discuss, Blind, Reddit, Indeed, and Nowcoder. Each report is translated where necessary, deduplicated against existing entries, and tagged by company, role, round type, and reporting date.
Use this question as one calibration data point, not a memorization target. Companies typically rotate their question pools every 2-4 months; the exact wording of a 2024 question may differ from what you encounter today. The underlying pattern, difficulty level, and follow-up depth at Yelp are the higher-signal extractions to take from this report.
For broader preparation context, the Yelp interview process typically includes a recruiter screen, one or two technical phone screens, and a 4-5 round on-site loop covering coding, system design (at L4+ levels), and behavioral. Reports tagged on LeakCode show the round-by-round distribution and typical difficulty calibration. To browse questions filtered by round type and seniority, use the company hub linked above.
How To Practice This Type of Question
Solve similar problems on LeetCode under timed conditions (25-35 minutes per medium difficulty). The goal is pattern recognition: recognize the underlying technique (sliding window, two-pointer, BFS, memoized recursion, etc.) within 60-90 seconds of reading. Strong candidates verbalize their hypothesis out loud before coding, then iterate based on feedback. Weak candidates dive into implementation immediately, lose time on the wrong approach, and run out of time for follow-ups.
Companies update their question pools every 2-4 months. The exact wording of any given question may have been retired by the time you interview. Focus your prep on the pattern, not the specific problem. The patterns that appear in Yelp reports consistently are the ones worth investing in; one-off niche problems are not.
During Your Yelp Round
Apply the standard interview round template: clarify requirements (2-3 minutes), state your approach out loud and confirm direction with the interviewer (3-5 minutes), code with narration (15-25 minutes), test with concrete examples including edge cases (5 minutes), discuss optimization or trade-offs if time permits (5 minutes). This template is universally accepted across FAANG and adjacent companies; deviating from it produces weaker interviewer feedback signal.
The single most predictive failure mode in Yelp reports tagged "no hire": not asking clarifying questions. Interviewers are explicitly trained to weight this. Strong candidates ask 3-5 clarifying questions even on problems that look obvious; weak candidates dive into code immediately. The clarifying-question check is often the first signal recorded in the interviewer's written notes.