UX поверх async-бэкендов: optimistic UI, состояния ожидания, read-your-writes

Окно консистентности теперь твоя проблема

В тот момент, когда запись перестаёт быть синхронной — уходит в очередь, на шину событий, к воркеру — появляется разрыв между «сервер принял» и «сервер вернёт это при чтении». Этот разрыв — окно консистентности. При нормальной нагрузке это может быть 50–300мс. При backpressure, отстающем консьюмере или ребалансе partition оно растягивается до секунд. Команда бэкенда видит в этом выигрыш по пропускной способности. Пользователь переживает это как то, что приложение забыло, что он только что сделал.

Первое, что это ломает, — read-your-own-writes: гарантия, что я вижу своё изменение немедленно, даже если другие пользователи ещё нет. Наивный сценарий — POST, потом рефетч списка — нарушает её постоянно, потому что рефетч гонится с консьюмером и обычно выигрывает. Собственная правка пользователя исчезает с его же экрана. Это самый частый «баг-призрак» на async-бэкендах, и он не случайный: это детерминированный итог доверия чтению, которое произошло внутри окна консистентности.

Optimistic UI: применяй локально, согласовывай потом

Рефлекс сеньора — optimistic UI: применить изменение к локальному состоянию в момент действия пользователя, отправить запрос в фоне и согласовать, когда придёт истина. Обоснование не эстетическое — это пороги восприятия, которые Нильсен задокументировал в 1993 и которые до сих пор держатся: ~100мс ощущается мгновенным (прямое манипулирование), ~1с удерживает пользователя в потоке, но он замечает ожидание, а ~10с — предел, за которым внимание рвётся и он считает, что всё упало. Async-пайплайн легко пробивает 1с по полному кругу, так что реальный round-trip быстрым не сделать — ты делаешь воспринимаемый ~0мс, рендеря предсказанный результат сразу.

У контракта три части, и третью джуны пропускают:

1. Применить предсказанное изменение к локальному состоянию и показать его.
2. Отправить запрос; сохранить достаточно контекста, чтобы откатить.
3. Согласовать — при успехе заменить предсказание серверной истиной (она может отличаться); при ошибке откатить к снимку, который ты взял перед применением.

Вместе эти три шага означают, что UI никогда не застревает с устаревшим предсказанием: либо сервер подтверждает и ты заменяешь на правду, либо отклоняет и ты откатываешь, как будто ничего не было. Пропусти шаг 3 — и ты отгружаешь ложь: оптимистичное значение висит на экране без пути коррекции.

TanStack Query кодирует ровно это в useMutation: onMutate отменяет рефетчи в полёте, делает снимок кэша и пишет оптимистичное значение (возвращая снимок как контекст); onError восстанавливает этот снимок; onSettled вызывает invalidateQueries, чтобы рефетчнуть реальное состояние. React 19 поставляет useOptimistic для облегчённой, привязанной к transition версии. Форма везде одна: снимок → предсказание → согласование-или-откат.

Состояния ожидания лучше фейкового успеха

Когда ты не можешь безопасно предсказать исход (платёж списан? видео перекодировано? экспорт готов?), честный ход — явное состояние ожидания/обработки, а не фейковое «готово». Покажи, что работа в полёте, дай ей аффорданс — шаг прогресса, ETA, «мы пришлём письмо» — и дай UI сойтись, когда событие придёт. Кардинальный грех — схлопнуть 202 Accepted в тост успеха: ты говоришь пользователю, что что-то завершилось, хотя оно ещё лежит в очереди.

Здесь живут два провала. Первый — бесконечный спиннер: UI ждёт событие, которое никогда не придёт (консьюмер упал, сообщение ушло в dead-letter — очередь недоставляемых сообщений), и крутится вечно. Каждому состоянию ожидания нужен путь timeout + согласование — через N секунд опросить авторитетный эндпоинт или показать «всё ещё обрабатывается, зайдите позже». Второй — двойная отправка при повторе: пользователь не видит обратной связи, кликает снова, и теперь в очереди два сообщения. Без idempotency key (ключ идемпотентности — уникальный токен, привязанный к намерению, который сервер использует для дедупликации повторных запросов) это два списания, два заказа, два письма.

Когда сталкиваются два async-обновления

Eventual consistency означает, что две записи могут быть в полёте одновременно — твоя и коллеги, или с твоего телефона и ноутбука. Согласование обязано выбрать победителя, и стратегия — это реальный трейдофф. Last-write-wins (LWW) штампует каждую запись timestamp и оставляет последнюю; это тривиально и без состояния, но молча отбрасывает данные проигравшего и зависит от синхронных часов — clock skew между нодами может дать победу более старой правке. Merge-логика (по полям или три-сторонняя) сохраняет обе стороны, когда изменения не пересекаются, но требует доменных правил. CRDT (conflict-free replicated data types) позволяют репликам слиться в любом порядке к одному результату без координации — основа real-time коллаб-редакторов — но накапливают метаданные и могут расти неограниченно без сборки мусора. Для «переименовать» LWW годится; для общего документа LWW уничтожает текст, поэтому тянешься к CRDT.

Работа фронтенда — сделать выбранную стратегию читаемой: если LWW отбросил изменение пользователя — скажи об этом и предложи применить заново; если произошёл merge — покажи, что слилось; вынеси 409 Conflict как реальный выбор («их версия / твоя версия / merge»), а не молчаливую перезапись.