In document data modelling, what makes a document an aggregate rather than just a stored record?

## The word "aggregate" An **aggregate** is a group of data treated as a single unit for retrieval, modification and consistency. The term predates document databases, but document stores are the family that took it literally: the storage engine's unit — the document — *is* the aggregate. That is why this style of database is often called *aggregate-oriented*, in contrast to the relational model, where a single conceptual thing is normally spread across several tables and reassembled by joins at query time. A stored record, by itself, carries no such claim. A row in a table is just a tuple of values; whether it forms a meaningful unit with other rows is expressed elsewhere, through keys and joins. A document, by contrast, physically contains its parts. When you store an order with its line items nested inside it, you have asserted three things at once: these are read together, they are written together, and they are consistent together. ## The three properties that make it an aggregate **Read together.** One lookup by identifier returns everything the operation needs. There is no second round trip to assemble the shape the screen or the API response wants. This is the property that makes document reads fast and predictable: the cost of loading an order is one key lookup, regardless of how many lines it has. **Written together.** A document store gives you atomicity over a single document essentially for free — the update either lands entirely or not at all. Anything inside the boundary can be changed in one indivisible step. Anything outside it cannot, without extra machinery. **Consistent together.** Rules that must never be observed broken — a total that must equal the sum of its lines, a status that must not be *shipped* while a line is unallocated — can only be enforced cheaply *inside* one aggregate, because that is the widest scope a single write covers. ## An example ```json { "_id": "ord-4821", "customerId": "cus-77", "status": "placed", "lines": [ { "sku": "KB-01", "qty": 2, "unitPrice": 4900 }, { "sku": "MS-14", "qty": 1, "unitPrice": 2900 } ], "total": 12700 } ``` The lines live inside because no use case wants a line without its order, and because `total` must agree with them at all times. The customer does **not** live inside: customers are read on their own, updated on their own, and one customer has an open-ended number of orders. `customerId` is a link across an aggregate boundary — a plain value the application resolves with a second lookup when it actually needs the customer's name. ## What this changes about how you design Because the aggregate is the storage unit, the boundary is not a documentation artefact — it is a physical decision with runtime consequences. Draw it too small and every operation becomes several reads and a multi-step write. Draw it too large and you load megabytes to change one field, and unrelated writers collide on the same document. The question that decides the boundary is behavioural, not taxonomic: *what does the application load in one go, and what must change in one go?* Two things that sound related on a whiteboard — a product and its reviews, a user and their activity log — often belong to different aggregates, because they are read on different screens, written by different flows, and grow at wildly different rates. Conversely, two things that look like separate entities — an order and its shipping address as captured at purchase time — often belong in one document, because the order's copy is a historical fact that must never change when the customer edits their address book. ## Where the boundary stops Outside the aggregate you have identifiers, not nesting. Crossing that line at runtime means a second read the application issues itself, and a multi-step write with no automatic all-or-nothing guarantee. Those costs are the price of the boundary and should be visible when you draw it, not discovered later. ## How to answer this in an interview Say what the aggregate is (a unit of retrieval, modification and consistency), say that the document is that unit in a document store, and then give the behavioural test — read together, written together, consistent together — with one concrete example of something you would nest and something you would link. Avoid answering purely in terms of "related data": relatedness is not the criterion, joint access and joint consistency are.