Should You Write to the DB First or Cache First? Practical Strategies and Consistency Tips

Introduction

In real‑world scenarios we often focus on caching, both in‑process (local) and out‑of‑process (distributed) caches. This article examines three key questions, starting with the fundamental dilemma: should you write to the database (DB) before the cache, or the other way around?

1. DB First, Cache Later

Many developers assume the database is more important than the cache, so they naturally write to the DB first. However, when the DB operation succeeds and the cache write fails (common with Redis or Memcached due to network issues), data inconsistency can arise.

One safe solution is to wrap the DB write and cache write in a transaction. If the cache write fails, the transaction rolls back the DB change.

begin trans
var isDbSuccess = write db;
if(isDbSuccess){
    var isCacheSuccess = write cache;
    if(isCacheSuccess){
        return success;
    } else {
        rollback db;
        return fail;
    }
} else {
    return fail;
}
catch(Exception ex){
    rollback db;
}
end trans

Even this approach has drawbacks: the transaction adds load to the DB, and in extreme cases a rollback may itself fail.

To avoid rollback failures, write to the cache using a delete operation instead of set . This trades an extra cache miss for the ability to recover from a failed rollback.

The pattern is known as Cache‑Aside (sometimes called the "Cache CAP" pattern).

Handling High‑Availability Databases

If the DB is replicated with a master‑slave setup, a cache miss may read stale data from a lagging replica. A naive fix is to periodically compare the replica data with the cache and update the cache when they differ, but this consumes resources and is hard to tune.

A more efficient approach is to perform a delete (or set) on the cache only after the replica has finished synchronizing. This can be achieved by using a short‑lived shared storage entry (e.g., a key with a 3‑second TTL) that signals the need to read from the master on the next cache miss.

begin trans
var isDbSuccess = write db;
if(isDbSuccess){
    var isCacheSuccess = delete cache;
    if(isCacheSuccess){
        return success;
    } else {
        rollback db;
        return fail;
    }
} else {
    return fail;
}
catch(Exception ex){
    rollback db;
}
end trans
// store temporary marker {key, value, expire=3s}
delete cache;

When a subsequent read experiences a cache miss, the system checks for the temporary marker; if it exists (within 3 seconds), it forces a read from the master, ensuring fresh data.

2. Cache First, DB Later

Writing to the cache before the DB is generally discouraged for data‑critical applications because caches are volatile. If the cache write succeeds but the DB write fails, the latest data exists only in the cache and can be lost if the cache crashes.

Even using a delete‑cache strategy requires that cache accesses be single‑threaded; otherwise concurrent reads may fetch stale data from the DB while another thread is still writing.

In high‑throughput scenarios where write latency is paramount and data accuracy is less strict, a "write‑behind" or delayed‑write mechanism can be acceptable.

3. Do You Need Local (In‑Process) Cache?

Distributed caches provide the statelessness required for horizontal scaling. Introducing a local cache adds complexity in keeping three layers—local cache, distributed cache, and DB—in sync.

Local cache is worthwhile only in limited cases:

Data that changes infrequently (e.g., daily updates).

Extremely high concurrency scenarios (e.g., flash sales).

Use‑cases tolerant of slight data staleness (e.g., view counts).

Even then, you must address consistency across multiple nodes, typically via either notification‑based updates (RPC/MQ) or consistent hashing that pins a given key to a specific node.

4. Consistency Between Local Cache, Distributed Cache, and DB

For single‑instance applications, simply apply local‑cache operations last. In multi‑node environments, synchronizing local caches is challenging. Notification‑based updates incur high coordination cost, while consistent hashing can be resource‑intensive and may lead to uneven load distribution.

A middle‑ground solution is to set short TTLs on the local cache or periodically pull fresh data from the distributed cache, accepting a bounded window of inconsistency.

Conclusion

When the database does not yet have high‑availability features, the recommended practice is to write to the DB first and use a delete‑cache operation, which provides a robust safety net. Once the DB becomes highly available, consider subscribing to binlog changes or using the temporary‑marker technique described above.

Local caches should be introduced sparingly and only after carefully weighing the added consistency burden against performance gains.