As a lead, how would you bound what any single read may pull in a large mapped model where eager defaults have accumulated?
answer
- relocate the decision, do not tune it
- low global floor, local widening
- large values behind a reference
- two budgets: round trips and volume
- prefer the failure you can see
basics
~20 sPush fetch decisions out of the mapping and into per-use-case plans, keep large values out of the rows that every read touches, cap what a collection fetch may return, and enforce a volume budget in tests - not only a statement count.
solid answer
~50 sThe goal is to move fetch decisions from a place where they are inherited to a place where they are paid for. Concretely: make **deferred the mapping default** so the global floor is as low as possible, and let each use case widen with its own plan; **externalise large text and binary payloads** so a wide value is fetched by reference rather than riding on every read of the object; **bound collection fetches** by paging them instead of pulling them whole; and **guard volume in the test suite** - objects materialised, result width or bytes per call - because a statement-count assertion passes while a read doubles in size. The tradeoff is honest and worth stating: this discipline produces more per-use-case plans and more forgotten-fetch errors, which are noisy but visible, in exchange for removing silent over-fetch, which is quiet but unbounded.
go deeper
Take away the shape of the rule: reads should ask for what they need rather than inherit it, and very large values should not sit on an object every read loads.
Be able to name the levers - deferred defaults, per-use-case plans, paged collections, large values behind a reference - and say what each one stops.
Show a migration that is safe: link by link, widening the reads that need it before flipping the default, with volume assertions added as you go so regressions are caught.
Argue the tradeoff explicitly. You are choosing noisy, visible, bounded failures over quiet, unbounded cost, and you are moving a cost decision to the people who pay it.
## Frame the problem correctly A large mapped model with accumulated eager defaults is not a performance bug; it is a **defaults problem**. Every mapping-level fetch decision is inherited by reads that did not exist when it was made, by teams that never saw it, and by endpoints whose authors are told the query looks fine. The work is to relocate the decision, not merely to tune it. A useful principle: **the global floor should be as low as it can be, and every widening should be local and attributable.** ## The levers, in the order they pay off 1. **Lower the mapping floor.** Move links to deferred by default. This is the highest-leverage change and the most disruptive, because reads that quietly relied on inheritance now have to ask. Sequence it link by link, starting with the links that are largest and least universally used. 2. **Externalise large payloads.** A large text or binary value mapped inline on an object is pulled by every read of that object. Store it in its own row or in an external store, map a reference, and fetch it only when a use case names it. This removes a whole class of over-fetch that no plan discipline can reach. 3. **Bound collections.** A plan that fetches an unbounded collection is an unbounded read. Page it, or answer the question a different way - an aggregate for a count, a top-N query for a preview. 4. **Make plans per use case, named after the use case.** Reuse is where plan discipline decays: a caller that needs less adopts the plan that already exists. 5. **Guard volume, not only round trips.** Two budgets, two assertions. ## What to enforce, and where | Guard | Where it lives | Catches | |---|---|---| | Objects materialised per call | test suite, per representative endpoint | graph creep from an inherited default | | Result width and bytes per call | test suite or a load check | a column added to a table every read touches | | Statement count per call | test suite | per-row repetition | | Payload size in production | metrics on the endpoint | drift that fixtures do not reproduce | | Review rule: a new eager mapping default needs justification | code review | the cheapest place to stop it | The review rule is the one that scales without tooling. Any change that widens a global default should have to answer: which reads of this object now carry it, and does each of them need it? A change that widens one plan only has to answer for its own callers. ## The tradeoffs to state out loud - **More plans.** Per-use-case fetching is duplication by design. Accept the duplication and keep the names use-case shaped, or you will grow one wide plan everyone attaches. - **More visible failures.** Deferring by default means links that were needed but not fetched now surface - as an extra read, or as an error when nothing is open to load them. That noise is the price of removing silence, and it is a good trade only if the team fixes rather than reflexively re-widens the default. - **A staged migration.** Flipping many defaults at once produces a wave of failures with no way to prioritise. Doing it link by link keeps each wave attributable. - **Ownership.** The mapping is usually owned by a platform or domain group, while cost is felt by endpoint owners. If the mapping can be widened without the endpoint owners noticing, the incentive is wrong; make widening a global default a reviewed, named act. ## Choosing the direction of error deliberately Every arrangement fails. The question a lead answers is *which* failure the system should prefer: - A **missing fetch** fails loudly, near the change, and is cheap to fix. - A **silent over-fetch** does not fail at all. It shows up months later as latency, memory pressure under concurrency, and an incident nobody can attribute to a commit. Preferring the first is the whole argument for a low global floor. It is also why "make it eager so nothing breaks" is the wrong instinct at scale: it trades a visible, bounded failure for an invisible, unbounded cost. ## What good looks like a year later - Mapping defaults are boring: small, bounded, genuinely universal links only. - Each significant read names its own shape, and the name says which use case it serves. - Large values live behind a reference, so no read pulls them by accident. - The test suite fails on volume regressions, not only on round-trip regressions. - When an endpoint gets heavy, the reason is findable at the call site rather than in a mapping file three modules away.
- How would you sequence flipping many eager defaults to deferred without a wave of breakage?Link by link, largest and least universal first. For each one, find the reads that return the owner, widen the ones that genuinely need the link with their own plan, then flip the default and let the remainder surface. Doing several at once destroys attribution: every failure could be any of the changes.
- Where does moving a large value out of the row create new problems?It splits a write that used to be atomic on one row, so the reference and the payload can diverge if one part fails. It also adds a second read for the use cases that do need the value, and a lifecycle question - what deletes the payload when the owner goes. Those are usually acceptable beside pulling the value into every read.
- Why is a review rule often more effective here than tooling?Because the expensive act is widening a global default, and that is a single, reviewable line. Tooling measures the consequence after it ships, across many endpoints; review stops it where it is written, at the moment someone can still explain which reads will now carry the link.
saying these in an interview costs you the question
- Fixes over-fetch endpoint by endpoint without touching the defaults that cause it.
- Flips every mapping default at once and loses the ability to attribute failures.
- Enforces only statement counts and calls the read path guarded.
- Keeps large text or binary values mapped inline and hopes plans will avoid them.
- Treats a forgotten fetch as worse than a silent over-fetch.