Challenge 2: Explain an fsync Policy Choice — Possible Solution
====================================================================

appendfsync always — fsyncs (forces the write to physical disk) after
EVERY single write command. This is the safest option — essentially no
data-loss window at all, since every write is durably on disk before
Redis considers it complete — but it's also the slowest, since every
single command now pays the cost of a disk sync rather than being
batched.

appendfsync everysec — batches writes and fsyncs roughly once per
second. This means, in the worst case, only the last ~1 second of
writes could be lost in a crash — a small, usually acceptable window —
while performance stays close to not fsyncing at all, since most
writes don't each individually pay the disk-sync cost.

appendfsync no — lets the OPERATING SYSTEM decide when to actually
flush the AOF file to disk (typically whenever it feels like it,
often every 30 seconds or on its own schedule). This is the fastest
option for Redis itself, but the largest data-loss window of the
three, and the least predictable, since it depends on OS behavior
rather than anything Redis controls directly.

WHY everysec IS THE COMMON DEFAULT MIDDLE GROUND: it captures nearly
all of always's safety (a maximum 1-second loss window is a very
different risk profile from potentially 30+ seconds under no) while
avoiding almost all of always's performance cost, since fsyncing once
per second is dramatically cheaper than fsyncing after literally every
write. For the vast majority of use cases, "lose at most the last
second of writes" is an acceptable trade for meaningfully better
throughput — which is exactly why it's Redis's typical recommended
default rather than either extreme.