ProgramGuru

Write-Through and Write-Behind Patterns

Write-Through and Write-Behind: start from the problem

See the responsibilities

Write requestCarries identity and version
PolicyImmediate source write or buffered work
Source dataReceives the required durable update
AcknowledgementStates exactly what has succeeded
Write request: Carries identity and version → Policy: Immediate source write or buffered work → Source data: Receives the required durable update → Acknowledgement: States exactly what has succeeded

A service changes a value that readers may also find in a cache. The write must define when the source changes, when copies change and what an acknowledgement promises. A fast cache update alone may not mean the durable data was saved.

This is a data and messaging pattern lesson. Follow the responsibilities, inspect the small JavaScript example and compare the design choices. The example is local teaching code; its boundary is explained before you apply the idea to a real service.

What you’ll learn

  • Explain the problem Write-Through and Write-Behind addresses and the roles involved.
  • Follow the example and distinguish this pattern from nearby alternatives.
  • Choose when the benefit justifies the extra responsibilities and testing.

How the responsibilities work

Write-through routes a write through a path that updates the source under a defined synchronous contract before declaring its required success. Write-behind accepts into a buffering path and persists later under its durability and recovery contract.

The local example contrasts an immediate write with a pending buffer. The buffer is only an array, so losing this process loses its pending value. A production write-behind service must name its actual persistent acknowledgement boundary.

Follow a small example

Read the JavaScript from top to bottom and compare the expected output. The values are chosen to make this pattern’s responsibility visible. This example runs in one local execution context; it does not create remote services, durable storage or production access controls.

JavaScript · local teaching example

const store = new Map();
const pending = [];
function writeThrough(key, value) { store.set(key, value); }
function writeBehind(key, value) { pending.push({key, value}); }
writeThrough('A', 10);
writeBehind('B', 20);
console.log(store.has('A') + ' | ' + store.has('B'));
for (const job of pending) store.set(job.key, job.value);
console.log(store.get('B'));

Expected output

true | false
20

Choose a design and inspect the consequence

Compare the design choices

The product promises no accepted-order loss on process failure.
Two deferred updates for one key can arrive out of order.

Compare the visible consequences. With JavaScript enabled, choose an option in each scenario to assemble your decision record.

This is an exploratory design exercise. It does not run infrastructure, measure capacity or replace the lesson’s quiz.

Use the consequences to explain your decision, including the simpler alternative.

Apply the pattern to two situations. Select one option in each situation to build a decision record. Every option and its consequence stays visible, and you can change your choices.

When it helps—and what it costs

Use synchronous persistence where the success contract requires it. Evaluate buffering only when its durability, delay, ordering and recovery obligations fit the workload.

Synchronous paths add dependency delay; deferred paths add recovery and possible-loss risk. Two independent source/cache writes are not automatically atomic. Handle partial errors, repeated flushes, overwrite ordering and invalidation for other copies.

Distinguish the neighbouring patterns

Cache-Aside describes the miss path. An Outbox connects a local transaction with later publication. A cache-write queue is not automatically an outbox or an authoritative transaction log.

Follow read coordination on a miss, durable publication intent, acknowledgement boundaries to compare the specific responsibility before combining patterns.

For further reading, use Redis persistence documentation for the chosen durability boundary. Compare it with this original example and the guarantee required by your application.

Check your pattern reasoning

In the example, has B reached the store before flushing?
Choose one answer. You can try again.

Answer and explanation

No; it only exists in the pending array.

Acceptance into memory differs from persistence.

Check your pattern reasoning

Does synchronously updating two independent stores make them atomic?
Choose one answer. You can try again.

Answer and explanation

No; the commit and partial-failure contract still needs design.

Both steps can have separate failure boundaries.

Name the responsibility before choosing the pattern

For Write-Through and Write-Behind, describe the problem, the participating roles and the observable contract. Use the example as a starting point and test the boundaries identified in the trade-offs. A pattern name alone does not establish correctness or performance.

Return to the design-pattern guide to compare families, or apply the idea alongside acknowledgement boundaries.

Reaching the recap and completing the quizzes are separate milestones.

    Next lesson: Publisher/Subscriber Pattern →