Exercise 3: What "Only Under Load" Suggests — Possible Solution ==================================================================== WHAT THIS CHAPTER SAYS THE PATTERN SUGGESTS ------------------------------ Per this chapter's tip-box, "a problem that appears only during busy periods and disappears when traffic is light is a strong hint toward something with a fixed capacity - a connection pool, a cache, a rate limiter - rather than a straightforward code bug that would fail the same way regardless of load." WHY THIS DISTINGUISHES IT FROM A STRAIGHTFORWARD CODE BUG ------------------------------ A genuine code bug (a logic error, a bad calculation, a null reference) would be expected to fail consistently whenever the specific code path that triggers it runs - it wouldn't care whether traffic is high or low, only whether that particular path executes. A problem that instead correlates specifically with load implies something that only becomes a problem once a limited resource is exhausted - which only happens once enough concurrent demand exceeds that resource's fixed capacity. WHY THIS FORESHADOWS LATER CHAPTERS ------------------------------ Per this chapter, "Chapters 3 and 4 build directly on this instinct" - connection pools (Chapter 3) and caching (Chapter 4) are both exactly the kind of fixed-capacity resource this pattern points toward: a pool has a fixed number of connections, and cache behavior under heavy simultaneous load (e.g. a stampede) only manifests once concurrency is high enough. WHY THIS WORKS AS AN ANSWER ------------------------------ It states the chapter's own specific claim (fixed-capacity resource, not a straightforward bug), explains the underlying reasoning for why load-correlation points toward capacity limits rather than pure logic errors, and connects it to the specific later chapters the chapter itself references.