Untitled Lesson
Skill Matrix
UNLOCK NODES BY LEARNING NEW TAGS.
What is the fundamental risk write-back caching deliberately accepts in exchange for dramatically higher write throughput?
💻 Code Challenge | +75 XP
Implement a write-back view counter that increments a value in Redis immediately and flushes batched counts to the database every 30 seconds, with a written justification for why view counts are an appropriate use case for this pattern's data-loss tradeoff.
A team applied write-back caching to a payment amount field for performance reasons, and a Redis crash before the next scheduled flush resulted in permanently lost transaction data. Reorder the steps to fix this architectural mistake.
Task: Reorder the blocks in logical sequence to solve the problem.
A.D.A. Interface
Adaptive Didactic Assistant
Pascual Vila
Frontend Instructor // Code Syllabus
The Error //
Applying write-back caching to data where any loss is genuinely unacceptable, such as financial transaction records
// Wrong: unacceptable to lose, even rarely
await redis.set(`pendingCharge:${orderId}`, amount); // write-back, could be lost entirely
// Correct: durable pattern for genuinely critical data
await db.transactions.insert({ orderId, amount }); // write-through or direct, not write-backThe Solution //
Write-back deliberately trades some durability for higher write throughput — a write acknowledged as successful can be permanently lost if the cache fails before its deferred database flush occurs. This tradeoff is only appropriate for data where such loss is genuinely tolerable (a view counter being off by a few), never for data requiring strict durability guarantees.
The Error //
Choosing an excessively long flush interval without considering the widened data-loss exposure window it creates
// Risky if loss tolerance is actually low: a wide exposure window
setInterval(flushToDatabase, 300000); // 5 minutes of potential loss
// Tuned to the actual acceptable risk for this specific data
setInterval(flushToDatabase, 10000); // 10 seconds, if that's the real toleranceThe Solution //
A longer interval between flushes to the database batches more writes together for efficiency, but correspondingly widens the window during which a cache failure would result in permanently lost, un-flushed data — this tradeoff needs deliberate tuning based on the actual acceptable risk for the specific data involved, not an arbitrary default.