больше нуляСТУДИЯ ЦИФРОВЫХ ПРОДУКТОВРазобрать задачу
Меню
ДЕМОНСТРАЦИОННЫЙ ПРОЕКТ

Поток.

Сбой проходит.
Заказ остаётся.

Заказ уже пришёл с сайта, а учётная система временно недоступна. Что увидит сотрудник и что произойдёт при повторной отправке? В «Потоке» этот путь можно пройти самому, включая сбой и восстановление.

Попробовать сценарийПрочитать историю
НАПРАВЛЕНИЕ
Операции и интеграции
СТАТУС
Собственный рабочий прототип
ДАННЫЕ
Учебные примеры, без клиентского внедрения
СИТУАЦИЯ И ЗАМЫСЕЛ

Вторая попытка не должна создавать второй заказ.

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

Мы сделали небольшую рабочую очередь. Каждое событие получает устойчивый номер. Когда связь пропадает, запись остаётся в очереди с понятным статусом. После восстановления её можно обработать повторно. Подтверждение от учебной учётной системы завершает действие.

Рядом находится журнал. В нём видно принятие заказа, сбой, повтор и подтверждение обработки. Повтор того же события не увеличивает число заказов. Это небольшой интерфейс, но в нём можно проверить важную договорённость между системами: повторять попытку и создавать новую сущность — разные операции.

ПРОВЕРЬТЕ САМИ

Откройте сценарий.
Посмотрите на результат.

ПотокИНТЕРАКТИВНЫЙ ПРОТОТИП

Учебная очередь работает в браузере. Реальная учётная система не подключена; состояние сбрасывается при перезагрузке.

Как устроена демонстрация

  1. Принять заказ и повторить то же событие: запись останется одна.
  2. Выключить учебную связь и попробовать обработку.
  3. Восстановить связь и завершить тот же заказ без создания дубля.

Для интерактивного примера нужен JavaScript. История и проектные решения доступны ниже.

ПРОЕКТНЫЕ РЕШЕНИЯ

Детали, на которых
держится сценарий.

01

Различать событие и попытку

Заказ WEB-1042 сохраняет один идентификатор при повторных нажатиях. Счётчик попыток относится к обработке этой записи. Поэтому сбой не превращает одну задачу в несколько независимых заказов.

02

Сохранять понятное промежуточное состояние

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

03

Показывать историю действий

Журнал объясняет результат каждой команды. Отдельно показаны число принятых заказов и число подтверждённых записей. Эти показатели относятся только к текущей учебной сессии.

ЧТО РЕАЛИЗОВАНО

Результат,
который можно проверить.

В браузере реализованы состояния очереди, журнал и распознавание повторного события. Данные учебные и живут до перезагрузки страницы. Надёжность серверной очереди и реальный обмен с учётной системой этот прототип не подтверждает.

ПУТЬ К ВНЕДРЕНИЮ

Следующий шаг —
ваш рабочий процесс.

В рабочем внедрении очередь должна храниться на сервере и переживать перезапуск. Нужны правила повторов, уникальные ключи, контроль зависших операций, права доступа и уведомления ответственного. Отдельно проверяется случай, когда учётная система уже записала заказ, но подтверждение потерялось. Пилот оценивают по потерянным событиям, дублям и времени восстановления.

Обсудить похожую задачу
НАЧНЁМ С ВАШЕЙ ЗАДАЧИ

Обсудим ваш продукт.
Посчитаем первый шаг.

Опишите, кому нужен продукт и что он должен делать. Уточним вводные, предложим первый этап и подготовим оценку. Можно начать без готового технического задания.

Обсудить проект в TelegramРазобрать задачу по шагам