Design a Proximity Service like Yelp – System Design Interview Walkthrough 2026

When an interviewer asks you to design a proximity service such as Yelp, they are looking for how you translate a user‑facing product into a set of scalable components. The conversation usually starts with a high‑level description, then narrows down to the hardest parts – real‑time geo queries, data freshness, and fault tolerance. Below is a walkthrough you can follow in a typical 45‑minute interview.

1. Clarify the Scope and Requirements

Begin by asking clarifying questions. This shows you care about the product and helps keep the discussion focused.

• Core functionality: Users search for businesses (restaurants, shops, etc.) near a latitude/longitude pair and filter by category, rating, price, or opening hours.
• Key operations:
  • SearchNearby(lat, lon, radius, filters) → list of businesses.
  • AddBusiness(businessInfo) → create.
  • UpdateBusiness(id, updates) → edit.
  • WriteReview(businessId, review) → add rating/comments.
• Non‑functional goals:
  • Low latency: < 200 ms for a typical search.
  • High availability: 99.9 %+ uptime, graceful degradation.
  • Scalability: Handle spikes (e.g., holiday weekend) without a major performance hit.
  • Data freshness: Updates (new business, rating changes) should be visible within a few seconds.
• Assumptions: Global coverage, read‑heavy workload, occasional write bursts. Mobile and web clients are out of scope for the design.

2. Identify Core Entities and Data Model

The location field is the linchpin for proximity queries, so it must be stored in a structure that supports fast radius searches.

3. Sketch a High‑Level Architecture

+----------------+      +----------------+      +-------------------+
|   API Gateway  | ---> |  Service Layer | ---> |   Geo Index Store |
+----------------+      +----------------+      +-------------------+
        |                       |                         |
        v                       v                         v
+----------------+      +----------------+      +-------------------+
| Auth Service   |      | Business Svc  |      | Review Service    |
+----------------+      +----------------+      +-------------------+
        |                       |                         |
        v                       v                         v
+----------------+      +----------------+      +-------------------+
|   Cache (CDN)  |      |   DB (SQL)    |      |   DB (SQL)        |
+----------------+      +----------------+      +-------------------+

• API Gateway: Handles request routing, rate‑limiting, and basic auth.
• Service Layer: Stateless microservices (BusinessService, ReviewService, SearchService).
• Geo Index Store: A dedicated datastore (e.g., Elasticsearch, OpenSearch, or a purpose‑built quad‑tree) that supports geo_distance queries.
• Cache: Frequently accessed search results or hot business profiles cached in Redis or an edge CDN.
• Primary DB: Relational store for strong consistency on business and review data.

4. Deep Dive: Geo‑Based Search

4.1 Choosing the Right Index

• R‑tree / Quad‑tree: Good for in‑memory, low‑latency lookups but harder to scale horizontally.
• Geohash + B‑tree: Encode lat/lon into a string; range queries become prefix scans. Works well with distributed KV stores.
• Elasticsearch: Provides built‑in geo_point and geo_distance queries, automatic sharding, and replication.

In an interview, mention that you would start with Elasticsearch for its out‑of‑the‑box capabilities and later consider a custom geo‑hash solution if cost or latency becomes a concern.

4.2 Query Flow

1. Client sends GET /search?lat=…&lon=…&radius=5000&category=restaurant.
2. API Gateway validates auth and forwards to SearchService.
3. SearchService checks the cache. If a miss, it builds a geo‑distance query and sends it to the Geo Index Store.
4. Geo Index Store returns a list of business IDs sorted by distance.
5. SearchService fetches the full business records from the primary DB (or a read‑replica) and enriches them with rating aggregates.
6. Result is cached for a short TTL (e.g., 30 seconds) and returned to the client.

4.3 Handling Data Freshness

• Write Path: When a new business is added, the BusinessService writes to the primary DB and simultaneously updates the Geo Index Store via an async message (Kafka).
• Eventual Consistency: The index may lag by a few seconds, which is acceptable for most user experiences. If stricter freshness is required, the service can perform a direct DB lookup for recent writes.

5. Scaling the System

• Read‑Heavy Load: Deploy multiple SearchService instances behind a load balancer. Use read replicas for the primary DB to spread the query load.
• Sharding: Geo Index Store shards by geohash prefix, ensuring queries hit only relevant shards.
• Cache Warm‑up: Pre‑populate cache for popular locations (city centers) during off‑peak hours.
• Back‑pressure: Use circuit breakers to protect downstream services when latency spikes.

6. Trade‑offs and Alternatives

Discuss why you might pick one over the other based on the product’s SLAs and budget.

7. Typical Follow‑Up Questions

1. How would you handle “search near me” with a moving user – talk about continuous location updates, caching per session, and short TTLs.
2. What if the service must support ranking by relevance (e.g., rating + distance) – introduce a scoring function that combines normalized distance and rating, possibly using Elasticsearch’s function score.
3. How to prevent hot‑spot overload in a popular city – implement request throttling per IP, use geo‑partitioned caches, and consider a read‑only replica for that region.
4. How to store and query opening hours efficiently – store as a bitmask per day, enable range queries for “open now”.
5. How to ensure data privacy for user‑generated reviews – encrypt sensitive fields, apply access controls, and purge data on request.

8. Sample Answer Snippet (45‑90 seconds)

"For a Yelp‑style proximity service, I’d start by defining the core APIs: a SearchNearby endpoint that takes latitude, longitude, radius, and optional filters, plus CRUD operations for businesses and reviews. The biggest technical challenge is the geo‑search, so I’d use Elasticsearch’s geo_point type to index business locations. When a user searches, the request hits an API gateway, which forwards to a stateless SearchService. The service first checks a Redis cache; on a miss it queries Elasticsearch for IDs within the radius, then fetches the full business records from a read‑replica of our relational DB. Writes go to the DB and are streamed via Kafka to update the Elasticsearch index asynchronously, giving us sub‑second freshness. To meet low‑latency goals, I’d shard the index by geohash prefix and place read replicas close to the users. For availability, we’d run multiple service instances behind a load balancer and use circuit breakers to protect downstream components. Trade‑offs include accepting slight index lag for faster writes, and higher operational cost if we use a managed Elasticsearch service versus a custom geo‑hash solution."

9. How to Practice This

1. Mock the interview: Use a timer and walk through the steps aloud, as if you were explaining to a colleague. Record yourself to catch filler words.
2. Build a mini prototype: Implement a simple SearchNearby using a geohash library and a small dataset. Observe latency and experiment with caching.
3. Review follow‑up questions: Write bullet‑point answers for the typical follow‑ups listed above. Practice switching between high‑level design and deep dives without losing context.

---

Tip: When rehearsing, let Call Assistant listen to your answer. It can surface a concise version grounded in your résumé and keep the conversation on track, helping you refine the narrative before the real interview.