What practical failure modes appear when a repository's 'collection-like' illusion breaks down at scale - for example with large aggregates, deep object graphs, or eager/lazy loading choices hidden behind a simple findById call?

## The interface is silent about cost A repository's collection-like interface is **deliberately silent about cost** — `findById` looks the same whether it fetches one small row or triggers a cascade of joins across a dozen tables to hydrate a deeply nested aggregate. That silence is fine at small scale, where every aggregate is cheap regardless of how it's fetched, but it stops being fine once aggregates grow large, traffic grows high, or both, and the gap between 'what the interface promises' (a cheap in-memory-feeling operation) and 'what it actually costs' becomes a production problem rather than a theoretical one. ## The first failure — loading strategy behind a trivial-looking call The most common concrete failure is the **N+1 query problem** surfacing through a repository method that looks trivial. - If an `Order` aggregate has a collection of `OrderLine` children, and the repository's implementation uses an ORM with lazy-by-default associations, a naive `findAll()` over a page of orders can trigger one query for the orders themselves and then one additional query per order to fetch its lines — a hundred orders means a hundred and one round trips instead of one or two well-designed queries. - The reverse mistake, eager-loading everything by default 'to be safe', causes the opposite problem: a single `findById` on an `Order` with many lines, each with nested value objects, can produce one enormous join that pulls far more data than the current use case needs, even when the caller only wanted to check the order's status. ## The second failure — expensive writes hidden behind save A second failure mode is **expensive writes hidden behind** `save()`. If the aggregate boundary is large — say, an `Order` aggregate that embeds not just its own lines but a full audit-log history as child entities — then changing one field (marking the order as shipped) can mean the repository implementation re-persists, or at least re-evaluates, the entire aggregate graph on save, because the 'save the whole aggregate atomically' contract doesn't distinguish between a one-field change and a wholesale rewrite. At low volume this is invisible; at high write throughput on a hot aggregate, it becomes a measurable bottleneck and a source of increased lock contention or transaction duration. ## The third failure — staleness and identity A third, subtler failure mode is about **staleness and identity, not raw cost**: the collection illusion suggests aggregates behave like objects sitting in a stable in-memory set, but two concurrent requests each calling `findById` on the same aggregate get two independent, disconnected copies. If both copies are mutated and saved without an optimistic-concurrency check (a version column, an ETag-style check), the second save silently overwrites the first's changes — a **lost update**, which is exactly the kind of bug the 'it feels like an in-memory collection' framing can lull a team into not worrying about, because in a genuinely single in-memory collection there'd be only one aggregate instance for both requests to share, not two independently mutated copies. ## The underlying trade-off, and the levers The underlying trade-off across all three failure modes is the same one aggregate design always faces: transactional consistency and invariant enforcement (the reason the whole aggregate must load and save as one unit) versus the cost of moving and locking that whole unit on every operation. The fix is rarely 'make the repository smarter' — it's almost always to **make the aggregate smaller**. 1. Splitting a large aggregate so that parts not required for the same transactional invariant become separate aggregates, referenced by ID rather than embedded, shrinks what any single repository operation has to move. An audit-log history, for instance, rarely needs to be transactionally consistent with the order's current state in the same way line items and total do — it can become its own aggregate (or even a pure event log outside the aggregate model entirely), removing it from the `Order` repository's load/save cost. 2. Where the aggregate genuinely can't shrink further without losing a real invariant, the remaining lever is being deliberate about loading strategy per relationship (explicit eager for what a given use case always needs, explicit lazy or a separate query for what it usually doesn't) rather than leaving it to a framework's default, and adding optimistic concurrency checks so lost updates fail loudly (a version conflict exception) instead of silently. ## A concrete scenario A concrete scenario: a SaaS billing system's `Invoice` aggregate originally embedded every line item plus a complete history of every edit ever made to it, and `invoiceRepository.findById` became measurably slow as customers accumulated years of edit history, because every load pulled the entire history graph regardless of whether the caller just needed to check the current total. The fix was to split the edit history into its own `InvoiceHistory` aggregate (or an append-only event store), referenced by the invoice's ID rather than embedded, and to add a version column checked on save so that two concurrent edits to the same invoice fail one of them with a conflict rather than silently losing one edit — restoring both the performance the illusion had been quietly hiding, and the concurrency safety the illusion had been quietly assuming.