Section 1: Four Systems Wearing One Apron - Problem Understanding & Clarifications

Executive Summary: This section covers the opening minutes of a Staff/Principal interview built around a salad restaurant's ordering app — a prompt that sounds like a weekend CRUD project and is anything but. We decompose it across what, who, why, and how, then walk the clarifying exchanges that matter: the one that reveals the ingredient as the system's atomic entity, the one that separates app-thinkers from restaurant-thinkers, and the scoping answers that keep payment and allergens honest. You'll leave with an assumptions table, two reflexes that govern everything downstream, and a first look at Via Verde Salads — the running example that carries the next eleven sections.

You've drilled "design WhatsApp" until the Kafka topology recites itself. The principal engineer across the table smiles and reads from a card:

"Imagine we're building the ordering application for a salad restaurant. The restaurant has a set menu of salads it composes, but customers can also build their own salad from a menu of ingredients. Design the system."

A salad shop. Part of you relaxes — and that's the part to watch. A prompt this small isn't a gift from a Staff-level panel; it's a stress test with the scale stripped out. There's no Kafka topology to recite your way through, no sharding debate to run out the clock on: the traffic genuinely is tiny (Section 3 proves it on a napkin), so every minute goes to what scale usually obscures — judgment. Can you hear what the prompt's own words say about the domain? Do you model a kitchen the way kitchens actually work? Does your discipline survive a problem that looks unworthy of it? The wreckage comes in matching pairs: the candidate who sketches a salads table before asking a single question, and the one who summons microservices for a workload that would embarrass a Raspberry Pi. Either way, the interview is lost inside the first ten minutes.

Key Insight: A deceptively simple prompt inverts the usual test. In "design Uber," the challenge is knowing enough machinery. Here, the challenge is restraint plus domain attention — the prompt already whispers its hardest design decision ("build their own salad from a menu of ingredients"), and the interviewer is watching to see whether you hear it before you draw a box.

Decomposing the Innocent Sentence

Every system, from this salad shop to a global payments network, yields to the same four-way decomposition. Map the territory before asking a single question:

• What it does: Strip the prompt to its verbs — browse a menu, compose a salad (preset or build-your-own), order, and implicitly fulfill: somewhere, a human has to make the thing. That last verb, the one most candidates never say aloud, hides the entire second half of this module.
• Who uses it: Three audiences, not one. Customers browse and order; kitchen staff receive, make, and — crucially — run out of things; managers set menus and prices. Three roles, three trust levels, one system.
• Why it exists: Revenue through convenience — order ahead, skip the line. So the system's promises (price, availability, pickup time) are commercial promises; a wrong one costs money or a customer.
• How it's used: A phone in one hand, often while walking, mostly in a ferocious 60-minute window around noon. Human-paced, bursty by lunch physics, intolerant of lies, tolerant of a few hundred milliseconds.

Read the four answers together and this section's title stops being a metaphor: inside "an ordering app" hide a menu catalog, a pricing engine, an inventory truth, and a kitchen queue — four systems wearing one apron.