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

Пользователь жмёт «Опубликовать», спиннер останавливается, тост говорит «Опубликовано!» — а поста нигде нет. Тикеты в саппорт растут. Баг: POST вернул 202 Accepted и сбросил работу в Kafka-топик; консьюмер пишет пост через ~800мс. Фронтенд воспринял 202 как 200, рефетчнул список до того, как консьюмер отработал, получил пустой результат и поверил ему. UI был не медленным. Он был уверенно неправ насчёт записи, которой ещё не было.

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

В тот момент, когда запись перестаёт быть синхронной — уходит в очередь, на шину событий, к воркеру — появляется разрыв между «сервер принял» и «сервер вернёт это при чтении». Этот разрыв — окно консистентности. При нормальной нагрузке это может быть 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. Согласовать — при успехе заменить предсказание серверной истиной (она может отличаться); при ошибке откатить к снимку, который ты взял перед применением.

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»), а не молчаливую перезапись.