At what point does defaulting to Lazy Load across a whole persistence layer become the wrong architectural choice, and what goes wrong with naive lazy initialization when multiple threads share the same not-yet-loaded object?

## The bet Lazy Load is a **bet**: that deferring a load will save work on average because most callers won't need the deferred data, and that the savings outweigh the added complexity and the risk of hidden extra round trips or resource-lifetime bugs. Like any bet, it can be wrong, and a principal-level read of this pattern means being able to say precisely when it stops paying off, not just how to implement it. ## When almost every call site needs the data The clearest case where Lazy Load is the wrong default is when the 'lazy' data is actually needed by the overwhelming majority of call sites. If a Customer's `primaryAddress` is read by nearly every code path that ever loads a `Customer` at all, deferring it doesn't save anything on average — instead, it **guarantees** an extra round trip on nearly every access, because nearly every access is about to trigger the lazy load anyway, plus the overhead of maintaining the placeholder machinery itself. In that situation, eager loading (or better yet, restructuring the underlying query so the data comes back in the **same** round trip as the parent, via a join) is strictly better: - no wasted proxy/placeholder bookkeeping; - no chance of a stale-context exception later; - no N+1 risk at all, because there's no separate per-object trigger to accidentally run inside a loop. ## When latency has to be predictable A second case is systems with hard, predictable latency requirements — real-time or near-real-time paths where an occasional extra unplanned round trip (the cost of a lazy trigger firing at an inconvenient moment) is worse than a slightly higher but **constant** upfront cost. Lazy Load optimizes for average-case throughput at the cost of worst-case predictability: most accesses are fast because they skip work they don't need, but the ones that **do** trigger a load pay an unpredictable latency spike exactly when it's least expected, which is a bad trade for a system with strict tail-latency requirements. ## When many threads share the object A third case is heavily shared, long-lived, concurrently-accessed objects — caches, singleton registries, or any object read by many threads at once — where naive lazy initialization is actively **unsafe**, not just suboptimal. Consider a lazily-initialized field with the classic 'check if null, if so compute and assign' logic and **no** synchronization: 1. Thread A checks the field, sees null, begins the (possibly slow) load. 2. Before A finishes, thread B also checks the same field, **also** sees null (because A hasn't assigned yet), and **also** begins loading. 3. Now the load has happened twice, wasting work, and depending on what the load does (e.g., if it has side effects, or increments a counter, or opens a resource), doing it twice can be actively wrong, not just wasteful. Worse, even after A finishes and assigns the field, without a proper memory barrier there's no guarantee B (or any other thread) sees that write promptly, or sees it in a fully-constructed state — B could observe a reference to an object whose constructor hasn't fully 'published' from B's point of view, reading partially-initialized fields, which is a genuine memory-visibility bug, not just a logical race. ## Making the check-and-load safe The standard fixes for the concurrency problem all boil down to making the check-then-load-then-publish sequence **atomic and visible** in a well-defined way: - wrapping the whole check-and-load in a lock so only one thread performs the load and everyone else waits for it (simple, safe, but every access after the first pays a lock-acquisition cost even once loaded, unless you layer on a fast, unsynchronized read-path check after confirming the field is already set); - double-checked locking (check unsynchronized first, and only take the lock if it looks unset, then check again inside the lock before actually loading) done correctly with an appropriately memory-visible field (e.g., `volatile` in JVM terms) so the second check inside the lock reliably sees a fully-published value; - or delegating to a language/platform-provided thread-safe lazy primitive (an atomic compare-and-set on a reference, or a library-provided thread-safe value holder) that has already solved this correctly, which is usually the pragmatic choice over hand-rolling synchronization. ## The architectural lesson The architectural lesson for a whole persistence layer is that Lazy Load should be a deliberate, **per-association** decision made by looking at real access patterns — which associations are read together, which are rarely touched, which live on hot concurrent paths — rather than a single blanket default applied uniformly across every relationship in a domain model, because the pattern's payoff is entirely dependent on the actual shape of usage, and getting that shape wrong in either direction (lazy where eager was needed, or eager where lazy was needed) has a real, measurable cost.