Caching • Cache Patterns (Aside, Through, Back)Medium⏱️ ~2 min
Write Through and Write Around: Consistency vs Performance Trade Offs
Write through and write around are complementary write patterns that address different consistency and performance needs. In write through, the application (or cache) writes to the cache and synchronously persists to the source of truth before acknowledging the caller. This maximizes read after write consistency via the cache: a user who writes data can immediately read it from cache without a miss. The cost is higher write latency since the operation must complete two hops, and potential cache pollution where data that is never read still occupies cache memory. Write through is appropriate when users immediately re read what they write and the application can tolerate the extra latency, typically a few milliseconds for the added database write.
Write around bypasses the cache entirely on writes, sending updates directly to the source of truth without populating the cache. This avoids polluting the cache with cold write data that may never be read, preserving cache space for truly hot read traffic. The trade off is that newly written data will miss on the first read attempt, incurring a cache miss penalty of 1 to 5 milliseconds for a local database fetch. Write around is ideal for write heavy workloads with cold data where the majority of writes are not followed by immediate reads, such as logging, archival, or bulk imports.
In practice, large scale systems often mix patterns based on data characteristics. Hot entities or keyspaces where users frequently read what they just wrote use write through to maintain consistency and avoid miss penalties. Write heavy, cold data flows use write around to preserve cache capacity. For example, Reddit might use write through for comment creation (users immediately view their own comments) but write around for upvote aggregation batches that are computed asynchronously. Monitoring cache write amplification (ratio of cache writes to actual reads) helps identify when write through is wasteful and write around would be more efficient.
💡 Key Takeaways
•Write through provides strong read after write consistency: synchronous cache and database write before ACK, ensuring immediate reads hit cache without miss penalty
•Write through increases write latency by adding database persistence hop (typically few milliseconds), and can cause cache pollution if written data is never read
•Write around bypasses cache on write, avoiding pollution but causing cache miss on first read attempt with 1 to 5 millisecond local database fetch penalty
•Best practice is mixing patterns by keyspace: use write through for hot entities users immediately re read, write around for write heavy cold data like logs or bulk imports
•Cache write amplification metric (cache writes divided by subsequent reads) identifies wasteful write through; high ratio suggests write around more appropriate
•DynamoDB Accelerator (DAX) implements write through mode: writes go through DAX to DynamoDB synchronously, guaranteeing consistent read after write via cache
📌 Examples
Reddit comment creation with write through: User submits comment, server writes to cache and database synchronously, ACKs user. User immediately refreshes page and reads their comment from cache hit, avoiding miss penalty and providing instant feedback.
Netflix metadata ingestion with write around: Bulk import of catalog metadata writes directly to database, bypassing cache. Cache remains populated with frequently accessed titles. First user request for new title misses cache, loads from database, populates cache for subsequent requests.
Mixed pattern implementation: if (isHotKeyspace(key)) { cache.set(key, value); database.write(key, value); } else { database.write(key, value); } Monitor per keyspace hit ratio and write amplification to tune classification.