Cache Recovery Under Failure: Measuring the Trade-off Between Data Freshness and Database Load in Redis and Memcached

Abstract In-memory caches such as Redis and Memcached sit in front of most relational databases, and teams choose between them largely on feature lists and raw throughput. We ask a narrower question that prior work leaves open: when the cache fails and comes back, how much stale data does it serve, and how much extra load does the database absorb? We built a testbed with PostgreSQL as the source of truth, five cache configurations (Memcached cold and warm restart; Redis without persistence, with AOF, and with replica failover), three invalidation protocols, and an oracle that checks every cache read against the database’s commit history. Across 178 runs and 7.55 million reads, a 5 s cache outage under best-effort cacheaside invalidation produced a clear trade-off. Configurations that come back empty served essentially no persistent stale data but needed a median of 26.5 s to regain their hit ratio and sent 5,273 extra queries to the database. Configurations that come back warm recovered within the 1 s measurement resolution and added only 164 queries, but served 4.37–4.64% of post-recovery reads stale, across a median of 124 keys. The stale reads come from invalidations that were lost while the cache was unreachable and that the restored state then hid, so the difference follows the recovery mode, not the engine: Memcached’s warm restart behaved like Redis AOF. Retrying failed invalidations after reconnecting cut stale reads by a factor of at least 43 with no statistically detectable change in tail latency; re-sending a median of 158 deletes per run across the warm configurations raised net extra database queries from 164 to 310. Two extensions sharpen the picture. A network partition left even Memcached’s cold-restart configuration warm, and it then served 4.65% stale reads: what matters is whether the cache’s state survives. When the application lost its in-memory state during the outage, in a simulated restart, the in-memory retry queue lost its pending invalidations (1.77% stale reads), while a transactional outbox, which records them in the database, delivered them (0.06%) at the price of two extra statements per write; these applicationstate results are preliminary. Cache recovery is therefore a consistency decision as well as an availability decision.