The Question
Design

Local Business Discovery Platform

Design a local business discovery and review platform similar to Yelp. The system should support geo-based business search, structured business listings, user-submitted reviews and ratings, photo uploads, and personalized recommendations for millions of users across cities worldwide.
PostgreSQL
Redis
gRPC
Consistent Hashing
Sharding
Design Breakdown

Functional Requirements

Business Discovery: Users can search for businesses based on their geographic location (longitude/latitude) and category/keyword.
Reviews & Ratings: Users can post ratings and text reviews for businesses.
Business Management: Business owners can create and update business profiles (location, hours, photos).
View Business Details: Users can view a business's profile, including its average rating and recent reviews.

Non-Functional Requirements

Low Latency: Search results must return in under 200ms for a seamless user experience.
High Availability: The system must be available 24/7 for browsing and searching (Read-heavy).
Eventual Consistency: It is acceptable for a new review or business update to take a few seconds to appear in search results.
Scalability: Must handle millions of businesses and hundreds of millions of reviews.

Estimation

Total Businesses: 100 million.
Daily Active Users (DAU): 50 million.
Search Traffic: 50M users * 5 searches/day = 250M searches/day (~2,900 QPS).
Review Traffic: 5M reviews/day (~60 QPS).
Metadata Storage: 100M businesses * 2KB per record = 200GB.
Review Storage: 10B total reviews (historical) * 1KB per review = 10TB.
Read/Write Ratio: Extremely read-heavy (~50:1).

Blueprint

Concise Summary: A microservices-based architecture utilizing a geospatial index for location-based searching and a decoupled messaging layer for asynchronous search indexing.
Major Components:
API Gateway: Handles authentication, rate limiting, and routes requests to downstream services.
Search Service: Performs location-based queries using a Geospatial Index (PostGIS/Geohash).
Business & Review Service: Manages CRUD operations for business metadata and user reviews.
Geospatial Database: A specialized data store for efficient "nearest neighbor" coordinate queries.
Message Queue: Decouples review ingestion from search index updates to ensure low latency for the write path.
Distributed Cache: Stores frequently accessed business profiles to reduce primary database load.
Simplicity Audit: This design uses PostGIS for the MVP's geospatial needs rather than a custom QuadTree implementation, leveraging mature database features to minimize custom infrastructure.

High Level Architecture

Sub-system Deep Dive

Service

Topology & Scaling: Services are deployed as Docker containers in a Kubernetes cluster, scaling horizontally based on CPU/Request count.
API Spec:
GET /v1/search?lat=x&long=y&radius=5&term=pizza: Returns a list of businesses.
POST /v1/reviews: Submits a review (JSON payload with rating and text).
GET /v1/business/{id}: Fetches full profile details.
Communication: REST/JSON for external clients; internal gRPC for performance between the Search Service and Business Service.

Storage

Data Model:
Business Table: id (UUID), name, address, location (GEOGRAPHY), category_id, rating_avg.
Review Table: id, business_id, user_id, rating, comment, created_at.
Database Logic:
Primary DB: PostgreSQL with PostGIS extension. PostGIS uses R-tree indexing for efficient spatial queries (ST_DWithin).
Sharding: Businesses are sharded by Business_ID (consistent hashing) to distribute write load.

Cache

Data Structure: Redis Strings or Hashes.
Key Schema: biz:{business_id} stores the serialized JSON of a business profile.
TTL & Eviction: 24-hour TTL with LRU (Least Recently Used) eviction policy.
Logic: Cache-aside pattern. Search results return IDs; the UI or Gateway fetches full details from Redis.

Messaging

Topic Structure: review-updates-topic.
Logic: When a review is posted, the Business & Review Service publishes a message.
Consumer: The Search Indexer consumes messages to recalculate the rating_avg in the Geospatial DB for accurate filtering/sorting in search results.
Guarantees: At-least-once delivery; the indexer logic is idempotent.
Wrap Up

Advanced Topics

Trade-offs:
Consistency vs. Availability: Chosen Eventual Consistency (AP). If the Message Queue is delayed, the search index might show an old rating for a few seconds, but the system remains available for writes.
Bottlenecks:
Geospatial Index: A single PostGIS instance may become a bottleneck. Optimization would involve sharding the spatial index by Geohash prefixes (e.g., all businesses in the same city/region on one shard).
Failure Handling:
DB Replication: Use Leader-Follower replication for PostgreSQL. If the Leader fails, a Follower is promoted.
Queue Persistence: The Message Queue (e.g., Kafka) persists messages to disk to prevent data loss during consumer downtime.
Alternatives & Optimization:
Elasticsearch: For the MVP, PostGIS is simpler. However, as search complexity grows (fuzzy text search, complex filters), migrating the search index to Elasticsearch would provide better relevance scoring.
CDN: Use a CDN (CloudFront/Cloudflare) to cache static assets like business photos to reduce egress costs and latency.