Reddit's View Counter: 1.6 Billion Views Per Day
Reddit shows view counts on every post. At 1.6 billion daily page views, writing every view to PostgreSQL directly would overwhelm the database. Instead, Reddit uses write-back caching: views accumulate in Redis, then a background process flushes batches to the database every few minutes. If Redis crashes, they lose a few minutes of view counts - acceptable for analytics. But for upvotes (which users see immediately), they use write-through: every vote is written to both cache and database before confirming. Two caching strategies, one system, chosen by business impact.
Understanding write strategies is critical because every write-heavy system faces the same tension: your cache is fast (microseconds for Redis) but volatile (data lost on crash), while your database is durable (data survives hardware failures) but slow (milliseconds per write). How you coordinate writes between these two layers determines your system's consistency guarantees, write latency, and data loss risk.
Write Strategies Compared
Write Caching Strategies:
Strategy Write Path Trade-off
---------------- ----------------------- ----------------------
Cache-Aside App writes to DB only Cache may be stale
App invalidates cache App manages both
Next read populates Most common pattern
Write-Through App writes to cache Writes are slower
Cache writes to DB (wait for both)
Both sync before ACK Cache always fresh
No stale reads ever
Write-Back App writes to cache Risk of data loss
(Write-Behind) Cache batches to DB if cache crashes
async (every N sec) Writes are fastest
Batching reduces DB load
Write-Around App writes to DB only Cache misses on
Cache is NOT updated recently-written data
Only reads populate Saves cache space
Real-world pairings:
Financial balance: Write-through (zero loss tolerance)
View counter: Write-back (loss = a few missing counts)
Product catalog: Cache-aside (admin edits are rare)
Sensor data: Write-back + batch flushWhen to Use Each Strategy
The choice depends on three factors: how critical is data loss, how frequently is data written, and how often is recently-written data read immediately. Write-through is the safest because every write synchronously updates both cache and database - but it doubles write latency since the application waits for both to acknowledge. Write-back is the fastest because writes only hit memory, and a background process flushes to the database in batches - but if Redis crashes before flushing, those writes are gone. Cache-aside is the most common because it keeps the application in control and only caches data that is actually read.
The Hybrid Approach Used in Production
Most production systems do not use a single strategy. They combine strategies based on data criticality. A payment service uses write-through for account balances (losing a transaction is unacceptable) but write-back for session activity timestamps (losing the last heartbeat time is fine). An e-commerce platform uses cache-aside for product listings (infrequent writes, high reads) but write-through for inventory counts (users must see accurate stock). The key insight is: classify your data by loss tolerance, then pick the strategy that matches.
Implementation Pitfalls
Write-through has a subtle consistency issue: if the cache write succeeds but the database write fails (due to a constraint violation or network error), you end up with ghost data in the cache that does not exist in the database. The fix is to write to the database first, then the cache - so failures are always on the cache side, where data can be re-populated from the database. Write-back has a different challenge: ordering. If two rapid writes update the same key, the background flusher must ensure they reach the database in order. Without ordering guarantees, the database can end up with a stale value.
Interview Tip
When discussing caching in interviews, show you know write strategies beyond just cache-aside. The key insight: write-through guarantees consistency (both cache and DB always in sync) at the cost of write latency. Write-back gives blazing write speed (memory only) at the risk of data loss if the cache crashes before flushing. Most production systems use a hybrid: write-through for critical data (payments, auth) and write-back for best-effort counters (views, analytics).
Key Takeaway
Your write caching strategy should be driven by data criticality, not performance alone. For data where loss means financial liability, use write-through. For data where speed matters more than perfect accuracy, use write-back. For the majority of data that is read far more often than it is written, cache-aside is the right default. Always classify your data before choosing a strategy.