Redis as a Cache

Redis is an in-memory data store first — every read and write is served from RAM, which is what makes it fast enough to sit in front of a database on every request without becoming the new bottleneck. That speed comes with an obvious question: what happens to the data if the process restarts? Redis's own documentation on persistence lays out the honest answer: by default you have a choice, not a guarantee. RDB persistence takes point-in-time snapshots of the whole dataset at intervals; AOF persistence logs every write as it happens and replays the log on startup; the two can be combined; and — the option the documentation calls out explicitly as common for caching — persistence can be turned off entirely.

Whether to persist a Redis cache at all is a direct consequence of what a cold cache costs the system behind it, which is exactly what this module already worked out for cache-aside: a cache-aside cache that loses everything on restart just means every key misses once and gets repopulated from the backing store on the next read, at the cost of a brief spike in load on that store. If the backing store can absorb that spike, skipping persistence is the right call — it's one less thing to operate, and RDB's periodic fork-and-write has a real cost of its own. If the cache is standing in for data the backing store can't cheaply regenerate — a computed leaderboard, a session store with no other copy of "who's logged in" — losing it on restart is a real outage, not an inconvenience, and that's when RDB, AOF, or both earn their operational cost.