</> MAANG.io
system design · 301

Advanced

Master system design interviews with scalable architecture patterns, distributed systems, and real-world design challenges.

0/480 solved 0% complete

Section 6: Follow the Ramen - High-Level Architecture

Executive Summary: This section turns Section 4's contract and Section 5's two stores into a running system. We draw the components once, walk Sam's "ramen, open now, within 1 km" search through them with a timing at every hop (about 120 ms), follow an owner's edit from PlaceDB to the index, and defend the boxes missing on purpose: no per-result Reviews call, no CDN for search, no sharded PlaceDB.

The interviewer slides the marker across: "You've got your API and your data model. Show me the boxes, then walk me through one request." The trap is drawing twenty boxes and narrating none. Draw the fewest components that meet Section 2's numbers, then push a real request down every arrow.

The Whole System on One Board

Everything sits in three active-active regions, each a full copy of the read path (D3, D11). Here is one region, plus the write path that feeds all three:

High-level architecture: clients reach the API gateway through GeoDNS, which routes to the search service (result cache, geocoder, 64-shard index) and the details service backed by PlaceDB, with CDC and review aggregates flowing through Kafka to the index and cache invalidation

Component Job Key number
API gateway Auth, rate limits, location scrubbing 60 / 120 searches per min; logs at geohash5
Search service Stateless query planner: covering, shard routing, L2 re-rank, cursors ≤ 5,000 candidates per query
Result cache Up to 200 candidates with coordinates per (geohash6, query, filters, sort) TTL 60 s, ~40 GB per region
Search index Inverted index with geohash cell tokens, sharded by geography 64 shards, 24 nodes per region
Details service + cache Read-through place details 40 GB hot set, TTL 10 min
PlaceDB Source of truth, one writer region 400 GB, ~23 writes/s
Geocoder "near Union Square" → coordinates, behind a cache 80% hit, 50 ms timeout
Kafka + indexers CDC events keyed by placeId, applied per region edits visible p99 ≤ 5 min

Key Insight: The read path and the write path share no synchronous dependency. Search never waits on PlaceDB's primary, and the index is a derived, rebuildable copy (50K docs/s → 200M in ~67 min). That is what lets every region keep serving while the writer region has a bad day.

Quick check before moving on:

Sign in to continue reading

The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.

Sign in to read the full lesson

Sign in to MAANG.io

Use your Google or Microsoft account — no password to remember.

Continue with Google Continue with Microsoft

Please accept the terms above to continue.