How the interviewer opens it
“Design a restaurant review app like Yelp. Users should be able to find nearby restaurants, see ratings and reviews, and post their own reviews and ratings.”
The prompt is vague on purpose. The first few minutes are yours: narrow it to the core features and agree on the numbers before you draw anything.
What to clarify first
- scale
- traffic and read:write mix
- discovery behavior
- review rules
- review browsing
- latency
- consistency and durability
- restaurant information
- geographic density and skew
- scope boundaries
The answers stay with the interviewer. In a SysRound round, Alex answers them as an interviewer would.
Scope of a strong answer
Core requirements
- Search nearby restaurants by location, radius, keyword, category, and minimum rating
- View restaurant information, aggregate rating, and paginated reviews
- Create, edit, and delete the current user's review and rating
Usually out of scope
- Reservations, ordering, delivery, and payments
- Personalized recommendations
- Building authentication or a full fraud-detection system
- Restaurant onboarding and catalog ingestion
What interviewers probe
- Nearby discovery without scanning or losing good results
- A radius query must cross geographic index boundaries, combine text and rating filters, and rank a dense candidate set. Returning arbitrary nearby candidates before applying the other criteria can silently miss the best results.
- Correct ratings across retries, edits, deletions, and asynchronous indexing
- One logical review affects a unique user–restaurant record, a public aggregate, and a search document. Retries and edits make blind counter increments incorrect, while a database commit followed by a failed publish can leave discovery permanently stale.
- Review history and hot restaurant pages
- Review lists combine very large histories, concurrent inserts, and highly concentrated reads. A design that works for the first page can become slow deep in the list or overload the database when a popular page's cache expires.
Common mistakes
- Treating latitude and longitude as ordinary independent range indexes, or assuming a single geographic cell covers a circular search.
- Filtering or ranking an arbitrary small candidate set after retrieval and silently missing better matches.
- Calculating aggregate ratings by scanning reviews on the read path.
- Ignoring edits, deletions, retries, or concurrent mutations when maintaining rating totals.
- Writing the database and search index independently without a recovery path for partial failure.
- Sharding and streaming every operation before noticing that peak review traffic is only about 116 mutations per second.
The bar by level
- Mid-level (L4/E4)
- Defines the discovery and review flows, chooses a workable geographic index, models reviews with a user–restaurant uniqueness constraint, maintains sum/count correctly, and uses indexed pagination and basic caching. Can explain why public search may lag a successful review write.
- Senior (L5/E5)
- Owns the consistency contract and failure cases: concurrent edits, idempotent retries, atomic aggregate updates, reliable index propagation, and immediate author reads. Handles dense geographic queries, keyset pagination, and hot-page cache stampedes without unnecessary write-side complexity.
- Staff (L6+/E6+)
- Separates authoritative and derived state and gives concrete rebuild, reconciliation, and migration plans. Evaluates ranking quality versus retrieval cost, identifies when a per-restaurant aggregate becomes a contention limit, and adapts write ownership and freshness guarantees for multi-region operation or mass moderation.