Write-Back

Сначала кэш, постоянная запись — позже

В Write-Back изменение сначала сохраняется в кэше, после чего приложение может получить успешный ответ. В основное хранилище накопленные изменения отправляются позже — асинхронно.

application
    |
    v
  cache ----> response
    |
    | later
    v
write queue
    |
    v
primary store

Почему запись становится быстрее

Клиент не ждёт более медленное постоянное хранилище на критическом пути. Несколько изменений одного и того же значения иногда можно объединить перед записью, а поток обновлений — отправлять в хранилище более крупными партиями.

Такой подход полезен, когда скорость записи очень важна и система способна временно держать новые данные в промежуточном слое.

Но кэш временно становится единственным местом с новой версией

До сброса данных основной источник ещё не знает об изменении. Если промежуточный слой потеряет данные раньше, чем они будут надёжно записаны, подтверждённое пользователю изменение может исчезнуть.

Поэтому для Write-Back особенно важны долговечность очереди изменений, повторные попытки, порядок записи и поведение при сбоях. Чем сильнее система откладывает постоянную запись, тем больше данных может находиться «в полёте».

Write-Through и Write-Back оптимизируют разные стороны

Write-Through ждёт основное хранилище и тем самым увеличивает latency записи, зато успешная операция уже дошла до постоянного источника. Write-Back отвечает раньше, но переносит часть риска и сложности в асинхронную доставку изменений.