Challenge 3: Diagnose a Surprising Data Loss — Possible Solution
====================================================================

WHY THIS HAPPENED: save 600 1 tells Redis to take an RDB snapshot only
if at least 1 key has changed within a 600-second (10-minute) window —
meaning, in the worst case, up to 10 minutes of writes could exist
ONLY in memory, never yet captured in any snapshot, at the moment of a
crash. If the server restarted unexpectedly roughly 10 minutes after
the last successful snapshot, every job added to the queue during that
entire window was never written to disk in any form — RDB's snapshot-
based approach has no partial record of what happened between saves,
only the full state AT each save point. When Redis restarted, it
loaded the most recent RDB file, which simply didn't contain those
jobs at all, because they arrived after that snapshot was taken.

WHAT WOULD REDUCE THE LOSS WINDOW: switching to (or adding) AOF with
appendfsync everysec. Instead of relying on periodic full-dataset
snapshots taken at most every 10 minutes, AOF logs each write command
as it happens, fsyncing to disk roughly once per second — reducing the
realistic worst-case loss window from "up to 10 minutes" down to
"roughly 1 second." For a job queue where every lost job represents
real, unrecoverable unprocessed work (per this chapter's "needs real
persistence" framing), this is exactly the kind of case where AOF's
smaller window justifies its added overhead over relying on RDB's
save-point interval alone.