Exercise 3: What Would Actually Have to Change to Make Invalidation Reliable — Possible Solution ==================================================================== WHY THE FIX CAN'T LIVE INSIDE CachedPricingService ITSELF ------------------------------ This chapter verified the exact shape of the problem: CachedPricingService.get_price() has no way of knowing that stock_data changed, because nothing about updating stock ever calls back into the pricing cache - the two pieces of code were never connected. Adding more logic inside CachedPricingService (a timer, a periodic refresh) would only ever be a guess at how often stock changes, not a real fix - it would either invalidate too often (losing this chapter's own 19,566x cache-hit speedup for no reason) or too rarely (reproducing the exact stale-price bug this chapter verified, just with a smaller window). WHAT WOULD ACTUALLY NEED TO CHANGE ------------------------------ Following Software Architecture Fundamentals Chapter 6's own solution to a structurally identical problem: whatever code actually changes stock_data (an InventoryService-style component) would need to notify the pricing cache when a change happens - not by CachedPricingService polling for changes, but by the stock-changing code itself publishing an event ("stock updated for PROD-1") that CachedPricingService subscribes to and reacts to by calling its own invalidate(product_id). This is the exact event-driven shape Software Architecture Fundamentals Chapter 6 already verified working: OrderService never needed to know UserService existed, and here CachedPricingService would never need to know exactly which part of the system updates stock - it would just need to react whenever a "stock changed" event arrives, regardless of its source. WHY THIS IS THE SAME KIND OF FIX, NOT A COINCIDENCE ------------------------------ Both problems are the same underlying shape: two pieces of code that need to stay in agreement, with no direct call connecting them. Software Architecture Fundamentals Chapter 6 solved that for "an order was placed, and two other services need to react" using pub/sub. This exercise's own answer applies the identical mechanism to "stock changed, and the price cache needs to react" - the fix isn't specific to caching at all; it's the general answer to "how do two decoupled parts of a system stay correctly informed about each other," reused directly. WHY THIS WORKS AS AN ANSWER ------------------------------ The answer explains concretely why a fix inside CachedPricingService alone can't work (it has no source of truth about when to invalidate), identifies the specific missing piece (a notification from whatever changes stock), and ties that fix directly back to a previously-verified mechanism from this course's own sibling course rather than proposing a new, unverified idea.