Exercise 1: TTL-Based Expiry vs. Explicit Invalidation — Possible Solution
====================================================================

TTL-BASED EXPIRY'S TRADEOFF
------------------------------
Per this chapter, TTL-based expiry is "simple and reliable, but a
fixed staleness window is built in by design - too short and the
cache barely helps, too long and real staleness is guaranteed for that
whole window." Even when everything works exactly as designed, data
can be wrong for up to the full length of the TTL after it changes -
this isn't a bug, it's the accepted cost of the strategy.

EXPLICIT INVALIDATION'S TRADEOFF
------------------------------
Per this chapter, explicit invalidation "fails completely the moment
any code path updates the underlying data without also triggering the
invalidation - a direct admin script, a different service writing the
same table, or a bug that only invalidates on the 'happy path.'" This
strategy aims for zero staleness, but its reliability depends entirely
on every single write path remembering to trigger invalidation - a
single missed path breaks the guarantee completely, and unlike TTL's
bounded window, there's no automatic recovery once that happens.

WHY NEITHER IS SIMPLY "BETTER"
------------------------------
Per this chapter, "TTL-based caching accepts a known, bounded staleness
window up front; explicit invalidation aims for zero staleness but is
only as reliable as every single write path that's supposed to trigger
it." TTL trades a guaranteed-but-bounded staleness window for
simplicity and reliability; explicit invalidation trades that
bounded-but-guaranteed staleness for a theoretically-perfect but
practically fragile guarantee that depends on complete, correct
coverage across every code path that writes the data.

WHY THIS WORKS AS AN ANSWER
------------------------------
It states both strategies' specific failure modes as described in the
chapter, and explains why the comparison isn't "one is better" but
"each accepts a different kind of risk."