What does query-first, or 'design for the read', modelling mean in a document database?

## The inversion Most people learn to model by drawing the domain: here are customers, here are orders, here are products, here are the lines between them. Query-first modelling refuses to start there. It starts with a list of the operations the system must perform, and treats the document shape as an *output* of that list. The reason is structural. In a document database the shape you store is the shape you get back. There is no query planner that will reassemble a convenient view out of five stored pieces at low cost — assembling across documents is work the application does, one extra round trip at a time. So the shape is a physical commitment to a particular access profile, and committing before you know the profile is guessing. ## What an access pattern actually is A usable access pattern is more than "we need to get orders". It records: - **The entry point** — what identifier or filter the operation starts from. - **The shape returned** — which fields the caller actually renders or computes with. - **The cardinality** — one document, twenty, or an unbounded list. - **The frequency and the latency budget** — a call on every page load is a different constraint from a nightly report. - **Whether it reads or writes**, and if it writes, what must change indivisibly with it. A typical list for an e-commerce service looks like: *render order detail by order id (very hot, one document, needs lines and totals and the address as captured)*; *list a customer's recent orders by customer id (hot, up to 20, needs id, date, status, total only)*; *find orders by status for the fulfilment queue (moderate, unbounded, needs a summary)*; *recompute lifetime spend per customer (nightly, batch)*. That list, not the entity diagram, decides the documents. Order detail wants lines nested. The customer's recent-orders list wants only summary fields, which means either projecting a few fields out of the order documents or maintaining a compact list — a decision you can only make once you know how hot it is. The nightly batch wants nothing special, because a batch job can afford to scan. ## "Design for the read" does not mean ignore the write The slogan is a corrective to entity-first habit, not a claim that writes do not matter. A shape optimised purely for reading can be miserable to write: if serving the read requires the same value to sit in three documents, every update becomes three writes with a window where they disagree. The honest version of the rule is *design for the dominant access*, and in most interactive systems reads dominate by one or two orders of magnitude, so reads usually win — but you decide that by looking, not by assuming. The useful discipline is to write both columns next to each other: for each candidate shape, what does the hot read cost, and what does the hot write cost? A shape where the hot read is one lookup and the hot write is one document update is the ideal. A shape where the read is one lookup but the write fans out across many documents is a trade you may still take, deliberately, when reads outnumber writes heavily and some staleness is tolerable. ## Working the method 1. **Enumerate operations** from the API surface, the screens, and the jobs. Include the ones that only run at month end; they constrain nothing but they must remain possible. 2. **Rank them** by frequency times latency sensitivity. The top few earn the shape. 3. **Propose a document per aggregate** and check every operation against it: how many accesses does it take, and does it fetch data it discards? 4. **Look for the operations that came out badly** and decide, per operation, whether to accept the extra work, change the boundary, or serve it from a separate derived structure. 5. **Record the losers.** The patterns you consciously made expensive are the ones a future reader will otherwise "fix" by changing the shape and breaking the hot path. ## Failure modes The two symmetrical mistakes are modelling the entity diagram and modelling one screen. Entity-first gives you a tidy set of small documents and an application that issues six reads to render a page. Screen-first gives you a document shaped like today's user interface, which stops fitting the moment the interface changes; the guard is to shape against the *operation* — the data a use case needs — rather than the visual layout it is currently rendered in. The third failure is doing the exercise once. Access patterns drift as features land, and a shape chosen for last year's workload can quietly become the reason a page is slow. Query-first modelling is a habit applied whenever the workload changes materially, not a one-off ceremony at the start of a project. ## How to answer this in an interview State the inversion, give the anatomy of an access pattern, and walk one concrete operation from requirement to document shape. Then volunteer the limit yourself — that reads usually but not always win, and that you check the write cost of every read-optimised shape. Interviewers listen for whether you treat the slogan as a rule or as a trade you have actually priced.