Очереди, потоки, события
UX при eventual consistency: тест с выбором ответа
Шесть вопросов поперёк всего юнита. Каждый отражает UX-решение, которое ты принимаешь над реальным асинхронным бэкендом — не определение для заучивания, а компромисс, который надо взвесить, пока consistency-окно растягивается под нагрузкой.
Убедись, что связываешь consistency-окно, optimistic UI, read-your-own-writes, честные pending-состояния, идемпотентные retry и conflict resolution — тот синтез, к которому вёл урок.
POST кладёт работу в очередь и возвращает 202 Accepted за 40мс; consumer пишет строку ~700мс спустя. UI делает POST, а затем сразу рефетчит список. Что увидит пользователь и почему?
Ты подключаешь optimistic-обновление в TanStack Query useMutation. Какой шаг чаще всего пропускают джуны и что ломается без него?
Кнопка 'Оплатить' показывает спиннер. Событие, подтверждающее списание, не приходит, потому что consumer упал. Без дополнительной обработки что произойдёт?
Предсказуемое действие (переключение чекбокса, которое идёт через очередь, consumer пишет ~500мс спустя) показывается блокирующим спиннером до подтверждения consumer'ом. Что не так с этим UX-выбором?
Два пользователя одновременно правят тело одного общего документа; обе записи идут через очередь. Бэкенд разрешает конфликт через last-write-wins (LWW). В чём senior-критика?
Пользователь жмёт 'Отправить', не видит фидбэка, потому что pending-состояние не построили, и жмёт снова. В очередь падают два сообщения. Какой устойчивый корневой фикс?
Сквозная линия юнита — одно правило: асинхронная запись не читается мгновенно, поэтому consistency-окно становится проблемой фронтенда. Когда клиент может предсказать результат, используй optimistic UI — снапшот, предсказание, reconcile или rollback — чтобы выиграть ~0мс воспринимаемой задержки против порогов 100мс/1с/10с. Когда исходом владеет сервер, покажи честное pending-состояние с timeout, чтобы неприходящее событие не крутилось вечно, и никогда не сворачивай 202 в success-тост. Эхай записи локально вместо доверия гоночному рефетчу, ключуй retry, чтобы двойной клик не списал дважды, и разрешай конфликты осознанно — LWW для простых полей, CRDT для общего текста — делая исход читаемым, а не тихо перезаписывая пользователя.