</> 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 11: The Owner Signs Ten Leases - Follow-Up Feature Evolution

Executive Summary: This section answers the interviewer's closing move: the business explodes, and the design must grow four directions at once. The chain arrives as a shared ingredient/recipe catalog with per-location overlays (D12), menu publishing becoming a pipeline. Delivery platforms receive the structured recipe model through adapters — the syndication D1 quietly paid for in advance — with lossy mappings stated honestly. Loyalty, combos, and promos are pricing rules over the resolution step D3 already owns. And catering is the day D7's flip trigger finally fires: fifty-salad orders are capacity events, and for the first time, a reservation is real.

The whiteboard is full, the failure modes handled, and the interviewer leans back for the classic last question: "The owner just signed ten leases and a DoorDash deal. Marketing wants a loyalty program. A law firm down the street wants fifty salads every Thursday. What changes?" The question audits your earlier self: Section 1 scoped to one busy location but promised a design 500 wouldn't demolish; Section 5 claimed every future feature would be a query over the model, not a new table. Later is now. The losing answers are mirror images: a rewrite (the model couldn't grow) or a confession you secretly built all of this already (Section 2's scope discipline was theater). The winning answer walks each feature through a door left deliberately unlocked.

The Chain: One Catalog, Many Overlays

The reflexive design — copy the menu per location — is wrong. Ten copies are manageable; the design target of 500 is 500 slowly divergent forks, and the first company-wide price change becomes archaeology. D12 names the alternative: a shared ingredient and recipe catalog — one definition of avocado, one Harvest Cobb — with per-location overlays carrying only what genuinely varies: a price band (downtown's Harvest Cobb is $11.95; a suburb may sit a tier lower), local availability (each location's own 86 board, exactly as built), hours, and regional items. The downtown menu v47 Maya browsed doesn't change shape; it's now derived — catalog plus overlay — instead of authored directly.

That derivation turns menu publishing into a pipeline: draft against the catalog, regional review, then a publish step rendering one immutable versioned document per location (D4 and D6, unchanged — the CDN and the 30 KB doc never learn the chain exists). At 500 locations the write load is still comic relief — 300K orders/day is 3.5/s average, 35/s at the smeared national peak, well inside D5's one-database headroom. Governance scales; throughput never had to.

And the chain pays D1's first unexpected dividend. Because every order line snapshots a resolved ingredient list (D2), chain-wide reporting rolls up by ingredient with a GROUP BY, not an ETL project: which locations waste avocado? which 86 cashews every Tuesday? A modifier-string model answers neither without parsing free text from 500 stores.

One shared catalog plus per-location overlays feeding the publish pipeline, CDN, and platform adapters

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.