Challenge 1: Choose a Persistence Strategy — Possible Solution
====================================================================

(a) A pure cache in front of MySQL — NEITHER (or, at most, minimal RDB
purely for faster warm-starts). This is exactly the "acceptable to
lose" case this chapter named directly: every value in the cache can
be regenerated by simply querying MySQL again on the next request. A
crash losing the entire cache costs nothing but a temporary burst of
cache misses (and the resulting database load) right after restart —
not a real data loss, since Redis was never the source of truth for
this data. Spending effort on AOF's durability guarantees here
protects data that was disposable to begin with.

(b) A Redis Streams-based job queue with no other durable record of
pending jobs — BOTH, with AOF's tighter window prioritized (ideally
appendfsync everysec, or always if the jobs are especially high-value).
Here, Redis genuinely IS the only record of what work is still
pending — losing it on a crash means those jobs are gone forever, with
no other system holding a copy to recover from. This is precisely the
"needs real persistence" case: RDB alone would leave a real window
(minutes) of jobs that could vanish with no record they ever existed;
AOF's much smaller window is worth its performance cost specifically
because the jobs it protects have no other durable copy anywhere else.