Cache and Database Consistency: Cache-Aside vs Write-Through

The honest answer is perfect consistency between cache and DB is impossible without 2PC — you can only achieve eventual consistency with bounded staleness. The most common pattern is cache-aside: on read, the app checks Redis first; on miss, it loads from MySQL and backfills. On write, it updates MySQL and invalidates the cache. Two key decisions here. First, "delete or update the cache?" Always delete. Updating risks writing stale values — imagine two concurrent updates, A writes cache then B writes cache but A's DB write happens after B's; cache ends up with A's stale value. Delete + lazy rebuild avoids this. Second, "DB first or cache first?" DB first then delete cache is standard. Cache first risks the cache being stale if the DB write fails — you'd need a rollback mechanism. But DB-first has its own race: thread A writes DB, then another thread B reads, misses cache, reads DB — in replication setups B might read from a replica that hasn't caught up, then writes the stale value back into the cache right before A's delete fires. Two fixes are common: delayed double-delete — delete cache, write DB, sleep 500ms to let concurrent reads settle, delete cache again; and binlog-driven invalidation using Canal or Debezium to tail MySQL binlog and emit cache invalidations through Kafka, which a consumer applies to Redis. The binlog approach is the gold standard for strict use cases because the invalidation is guaranteed to happen exactly once with retries and doesn't depend on the write-path client to do the right thing. For less critical data, just TTL + cache-aside with "delete after DB write" works fine — set a 5-minute TTL and accept 5-minute staleness in the worst case. The choice depends on how much staleness the business tolerates.