Exercise 2: Why Compare the Cache to the Database First — Possible Solution
====================================================================

WHAT THE COMPARISON ACTUALLY TESTS
------------------------------
Per this chapter, checking the cache directly against the source of
truth for the same key ("redis-cli GET" vs. the equivalent database
query) is a direct test of whether the cache is actually the cause -
not an assumption.

WHY A MATCH RULES OUT THE CACHE ENTIRELY
------------------------------
Per this chapter, "if the two actually agree, the cache isn't the
problem at all - the 'wrong data' complaint is something else entirely
(a display bug, a genuine data error, or user confusion)." If the
cached value and the database value are identical, the cache is
faithfully returning exactly what the source of truth currently holds -
whatever is "wrong" about the data the user is seeing has to be coming
from somewhere else in the system, not the cache.

WHY ASSUMING IT'S A CACHE BUG COULD WASTE TIME
------------------------------
Per this chapter, "continuing to chase caching as the cause would be a
wasted detour" if the values actually match. Investigating cache
invalidation logic, TTLs, or write paths when the cache was never
actually wrong would spend real time on a layer that isn't responsible,
while the actual cause (elsewhere in the system) goes unexamined.

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains what the direct comparison actually proves either way (a
match rules the cache out; a mismatch confirms it), and connects that
to why skipping this check and assuming a cache bug risks wasted
investigation time.