Think Beyond the Happy Path
Before diving into the solution, consider these key challenges:
- How would you efficiently query businesses within a geographic radius when you have millions of businesses across the globe?
- How would you handle the read-heavy nature of this system where searches vastly outnumber new reviews?
- How would you prevent rating manipulation while still providing a responsive user experience?
- How would you design the database schema to support both geospatial queries and complex filtering?
You don't need to answer all of these right away. A Senior/Staff+ Engineer doesn't stop at basic functionality — they anticipate edge cases, design for resilience, and push for production-grade reliability.
But great systems start with great questions. What would you ask next?
Problem Statement
Design a business discovery platform like Yelp that allows users to:
- Search for businesses by location, category, and other filters
- View detailed business information including hours, contact info, and photos
- Rate and review businesses they've visited
This is a classic system design question that tests your understanding of geospatial data handling, search optimization, and building read-heavy systems at scale.
Functional Requirements
FR1 - Search for business entities by location
Users can search for businesses near their current location or a specified address. The search supports filtering by category (restaurants, hotels, etc.), rating, price range, and current availability (open now). Results should be sortable by distance, rating, or relevance.
FR2 - View business details
Users can view comprehensive business information including exact location on a map, contact details, operating hours, menu or service offerings, photos, and a summary of reviews. This page serves as the primary conversion point for users deciding whether to visit a business.
FR3 - Review a business with rating and optional text
Authenticated users can submit reviews consisting of a 1-5 star rating and optional text commentary. Users may also attach photos to their reviews. To maintain review integrity, each user can only submit one review per business within a configurable time window.
Non-Functional Requirements
NFR1 - Availability over Consistency
The system should prioritize high availability for all client operations. Search and view operations must remain available even during partial system failures. Review display can be eventually consistent - it's acceptable for new reviews to take a few seconds to appear to all users.
Why Eventual Consistency Works for Reviews
In a business review system, users don't expect to see reviews appear instantaneously across all devices. A delay of a few seconds is acceptable because:
- Review frequency is low - Users write reviews occasionally, not in real-time
- No coordination required - Unlike a chat system, reviews don't need to be ordered relative to each other
- Read-your-writes suffices - The reviewer should see their own review immediately, but others can wait
This allows us to use caching aggressively and replicate data asynchronously, significantly improving read performance and availability.
NFR2 - Scalability
The system should support 10 million businesses and 100 million monthly active users. Based on real-world data (Yelp has ~60M MAU as of 2024), this provides comfortable headroom for growth.
NFR3 - Performance (Read-Heavy)
Search and view operations should complete within 1-2 seconds. Given the read-to-write ratio (searches vastly outnumber reviews), the system must be optimized for read performance.
Back-of-the-Envelope Estimation
Let's estimate the query load:
- MAU: 100 million (round up from Yelp's 60M for safety margin)
- DAU: 20-30 million (assuming 20-30% daily engagement for a moderate-engagement app)
- Searches per user per day: 2-5
QPS Calculation:
- Lower bound: 20M users × 2 searches ÷ 86,400 seconds ≈ 460 QPS
- Upper bound: 30M users × 5 searches ÷ 86,400 seconds ≈ 1,740 QPS
- Peak (3x average): ~3,000 QPS
A well-optimized PostgreSQL instance can handle 10-20K QPS for spatial queries, so a single primary with read replicas should suffice initially.
NFR4 - Fault Tolerance
The system should gracefully handle component failures without complete service disruption. Failed components should be automatically detected and traffic rerouted to healthy instances.
NFR5 - Compliance
Each user can rate a business only once within a configurable time period to prevent rating manipulation and spam.