How to Prevent Cache Penetration, Avalanche, Breakdown, Inconsistency, and Concurrency Issues

Cache Penetration

Cache penetration occurs when a request queries a key that is absent both in the cache and in the database, causing the request to bypass the cache and hit the database directly. This often results from malicious attacks or programming errors and can lead to a sudden surge of database traffic.

Bloom filter : Before accessing the cache, check the key with a Bloom filter. If the filter indicates the key does not exist, return an error without querying the database.

Cache empty results : When a database query returns no data, store a short‑lived placeholder (e.g., a null value) in the cache. Subsequent identical requests hit the placeholder instead of the database.

Rate limiting : Limit request frequency per IP or user, and block or throttle abnormal traffic.

API authentication : Enforce strict parameter validation and authentication at the API gateway.

Database indexing : Ensure that unavoidable database queries use appropriate indexes for fast execution.

Two‑level cache : Use a local (in‑process) cache as the first layer and Redis as the second layer; only query Redis when the local cache misses.

Frontend validation : Perform input validation on the client side to avoid sending illegal requests.

Cache Avalanche

A cache avalanche happens when a large number of cached entries expire at the same time or the cache service crashes, causing a massive wave of requests to hit the database.

Randomize expiration times (add a jitter) so that keys expire at different moments.

Enable Redis persistence (RDB or AOF) and configure it properly to allow fast recovery after a restart.

Mark hot data as non‑expiring or update it manually to keep it continuously available.

Adopt multi‑level caching (e.g., local cache + Redis) to reduce reliance on a single cache tier.

Deploy high‑availability architectures such as master‑slave replication, Sentinel, or Redis Cluster.

Apply rate limiting and circuit‑breaker mechanisms to protect the database during traffic spikes.

Use asynchronous queues to defer database reads when a cache‑miss surge occurs.

Cache Breakdown (Cache Stampede)

Cache breakdown (or stampede) refers to the situation where a hot key expires and many concurrent requests simultaneously query the database, overloading it.

Use a mutex or distributed lock (e.g., SETNX) so that only one request populates the cache while others wait.

Set hot keys to never expire or refresh them proactively before expiration.

Apply the double‑cache (Cache‑Aside) pattern: keep the old cache alive while a new cache is being built, then switch.

Pre‑warm caches with scheduled jobs before the expected expiration time.

Choose reasonable TTLs for hot data to avoid simultaneous expiration.

Combine a distributed cache with a local cache to absorb traffic bursts.

Use read‑write splitting and load balancing for the database.

Data Inconsistency Between Cache and Database

Inconsistency arises when the synchronization strategy between cache and database is inadequate. Typical causes include writes that update only one layer, cache eviction while the database changes, network latency, or transaction rollbacks.

Cache update strategies :

Delayed double delete – delete the cache, update the DB, then delete the cache again after a short delay.

Write‑through / read‑through – let the cache manage reads and writes, ensuring both layers stay in sync.

Write‑behind – write to the cache first and asynchronously flush changes to the DB.

Database triggers : Use triggers to automatically refresh or invalidate cache entries when underlying tables change.

Transactional messaging : Wrap cache and DB operations in a single transactional message (e.g., using a message queue that supports transactions) so they succeed or fail together.

Eventual consistency : Run periodic background jobs that reconcile cache data with the source of truth.

Consistent distributed cache : Choose solutions with strong consistency guarantees, such as Redis Cluster with appropriate configuration.

Version or timestamp checks : Store a version number or timestamp with cached data and verify it on each read; if mismatched, reload from the DB.

Short TTLs : Force frequent cache refreshes by using relatively short expiration times.

Concurrent Data Access Issues

When multiple clients read and write the same data concurrently, race conditions can cause lost updates or inconsistent state. Common scenarios include counter increments, inventory deduction, distributed locks, and session sharing.

Redis transactions: Use MULTI / EXEC to execute a batch of commands atomically.

Lua scripts: Execute a Lua script so the entire logic runs as a single, indivisible operation.

Distributed locks: Implement locks with SETNX (or the RedLock algorithm) to serialize critical sections.

Optimistic locking: Use WATCH to monitor keys and abort the transaction if they change.

Pessimistic locking: Acquire explicit locks before performing high‑risk updates.

Rate‑limiting algorithms: Apply token‑bucket or leaky‑bucket mechanisms to control request rates.

Message queues: Serialize conflicting operations by routing them through a queue.