Exercise 3: Why the Hourly Timing Was Itself Real Evidence — Possible Solution
====================================================================

WHAT THIS CHAPTER SAYS ABOUT PERIODICITY
------------------------------
Per this chapter, "a stampede caused by a fixed TTL has a genuinely
distinctive signature: it recurs at a suspiciously regular,
clock-aligned interval - every hour, on the hour, if the TTL is exactly
3600 seconds. That periodicity itself is real diagnostic evidence, not
a coincidence worth ignoring."

WHY REGULAR, CLOCK-ALIGNED TIMING POINTS SPECIFICALLY AT A TTL
------------------------------
A TTL is a fixed duration counted from when a value was cached - if
many requests populate the same key at roughly the same moment
(e.g. shortly after a deploy or the first request after a cold cache),
their shared TTL means they'll all expire at roughly the same later
moment too. A spike recurring at a suspiciously exact, round interval
(every hour, on the hour) is consistent with a specific TTL length
counting down and expiring repeatedly - a coincidental, unrelated cause
would be far less likely to align this precisely and repeatedly with a
clock boundary.

WHY THIS SPED UP THE DIAGNOSIS
------------------------------
Per this chapter's worked example, recognizing "the clock-aligned
periodicity is the immediate tell" led directly to checking a specific
cache key's remaining TTL, which confirmed the theory (3542 seconds
remaining, close to a full hour) almost immediately - without the
timing pattern as a starting clue, diagnosing this would have required
searching much more broadly for an explanation, rather than going
straight to checking cache TTLs.

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains the chapter's own reasoning for why regular, clock-aligned
timing specifically implicates a TTL-driven cause, and connects that
recognition to how it directly narrowed and sped up the actual
investigation in the worked example.