An online restaurant marketplace often highlights each store’s best‑selling dishes, helping customers decide faster and helping merchants gauge what sells well. On the surface it looks like a compact “Popular items” shelf, but three questions drive the entire design: how do we define “popular”, how current must the answer be, and how do we serve it inexpensively across thousands of restaurant pages?
We will evolve the solution from a simple real‑time query to a batch‑processing system that publishes stable, reusable snapshots. If you’re new to this topic, keep one principle in mind: sorting the counts is trivial. The actual design problem is deciding which counts you can trust and what freshness guarantees the API can make.
A restaurant marketplace might display a small “Popular items” shelf on each store’s consumer page. The design tension comes from choosing a signal that honestly reflects popularity and from establishing how fresh the rankings need to be.
K menu items across a fixed set of time windows, such as 1 day, 7 days, and 30 days.30 to 60 minutes under normal conditions.50 ms when a cache hit occurs, and roughly 150 ms for reads that fall through to PostgreSQL.200k active restaurants, 20M orders per day, and about 80M order‑line facts per day, with a skew toward a small subset of restaurants.| Assumption | Order of magnitude | Used for |
|---|---|---|
| Active restaurants | about 200k | Partitioning and snapshot cardinality |
| Orders per day | about 20M | Ingest volume into immutable facts |
| Order‑line facts per day | about 80M | Batch scan size and daily rollup work |
| Restaurant‑page reads | bursty, repeat‑heavy | Redis cache value and hit ratio |
| Batch cadence | about 30 to 60 minute freshness | Spark job frequency and publish rate |
Top K per shelf | on the order of 10 to 50 items | Snapshot row width and response size |
These anchors justify why reads should hit a pre‑published snapshot keyed by (restaurant, window), instead of running a GROUP BY over raw orders for every page view.
Below the line (out of scope for this tutorial)
[!NOTE] Restaurant pages need fast, repeated reads. The rankings, however, come from slower batch work over finalized orders. The design must make that gap visible through freshness metadata and a clear correction path.