Functional: 1. Business owners create/update a listing with name, address, category, hours, photos 2. Users search nearby businesses by location (GPS or typed) with filters 3. Users view a business profile: details, rating, reviews 4. Users write/edit one review per business per user 5. Business owners reply to reviews 6. Business owners register/authenticate; platform verifies ownership Non-functional: 1. Low latency: <200ms p99 for search and profile reads 2. High availability: service stays up through node/AZ failure and traffic peaks 3. Durability & integrity: reviews never lost; one review per user per business enforced Workload: read-heavy, ~100:1 reads:writes
Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...
Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...
Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.
Define the data model. Identify the main entities, their attributes, and relationships. Consider the choice of database type (SQL vs NoSQL) and justify your decision based on access patterns...
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.