Какая система отвечает за исходные данные
Клиент, заказ или платёж могут одновременно отображаться в нескольких системах. Для каждого факта нужно договориться об основном источнике - «источнике правды» - и правах на изменение. Иначе две системы будут исправлять друг друга, а сотруднику придётся решать, какой версии верить. Таблица ниже показывает, как можно распределить эти роли
| Факт | Источник правды | Куда передаётся | Кто имеет право менять |
|---|---|---|---|
| Контакт клиента | система управления клиентами | рассылки, поддержка, отчётность | продажи и клиент |
| Движение денег / привязка оплаты к заказу | банк / учётная система соответственно | заказ, отчётность | уполномоченные системы и сотрудники финансовой службы |
| Остаток товара | складской учёт | сайт, продажи | склад |
Таблицу можно прокрутить вбок →
Источник определяют для конкретного факта, а не для всего объекта сразу. Например, банк подтверждает движение денег, а учётная система связывает оплату с заказом. Это разные сведения: формулировка «банк или учёт» без такого разделения оставляет конфликт версий нерешённым
Четыре механизма обмена, которые можно сочетать
Для проектирования в этой статье удобно разделить обмен на четыре базовых механизма: синхронный запрос, событие, очередь и пакетную передачу. Это рабочая архитектурная группировка; конкретные возможности зависят от используемых систем.
Событие сообщает о произошедшем изменении, очередь хранит сообщение до обработки, а пакетная загрузка задаёт периодичность передачи. Это не взаимоисключающие варианты: событие об оплате, например, может пройти через очередь
| Способ | Как работает | Подходит | Главный риск |
|---|---|---|---|
| Синхронный запрос | одна система запрашивает другую и ждёт ответ | когда ответ нужен прямо сейчас | зависимость от доступности второй системы |
| Событие | система сообщает, что что-то произошло | статусы, изменения заказа, уведомления | повторная доставка и порядок событий |
| Очередь | сообщение сохраняется до обработки по правилам выбранной очереди | массовые операции и нестабильные получатели | накопление сообщений, истечение срока хранения, ошибки подтверждения обработки |
| Пакет по расписанию | изменения передаются раз в период | отчётность и некритичная свежесть | устаревшие данные между загрузками |
Таблицу можно прокрутить вбок →
Выбирайте сочетание по допустимой задержке, объёму, цене потери и требованиям к согласованности. Для каждого маршрута отдельно зафиксируйте, достаточно ли подтверждения приёма сообщения или нужен уже выполненный результат
Надёжность строится вокруг повторов и сбоев
Проектируйте обмен с учётом повторной доставки и частичных сбоев. В рекомендациях AWS по асинхронному взаимодействию разобраны идемпотентная обработка, очереди ошибок, повторы, порядок сообщений и наблюдаемость[1]. Приём сообщения не равен выполнению операции: это должны различать и система, и сотрудник, который смотрит её статус
- идемпотентность - получатель распознаёт повтор по устойчивому идентификатору, проверяет сохранённый результат и не выполняет действие второй раз. Сам по себе номер в сообщении ещё не защищает от дубля
- очередь ошибок - сбойный элемент не пропадает, а ждёт разбора
- идентификатор корреляции - один процесс можно проследить через несколько систем
- политика повторов - понятно, сколько раз и с каким интервалом повторять
- сверка - отдельная процедура проверяет, что итоговые количества и суммы сошлись
Как выбрать архитектуру без лишней сложности
Пять вопросов перед разработкой
- какую задержку допустит бизнес: секунды, минуты, часы
- что хуже: временно устаревшее значение или недоступность всего процесса
- можно ли безопасно повторить операцию
- нужен ли строгий порядок событий
- как сотрудник узнает, что обмен сломан
Для ежедневного отчёта может хватить пакетной загрузки. Для оплаты, после которой разрешается отгрузка, нужны подтверждённый статус, допустимая задержка и защита от повторного действия. Событие с очередью - один из вариантов; сам выбор этого механизма ещё не делает маршрут надёжным
Что должно быть видно в контроле обмена
| Метрика | Что показывает |
|---|---|
| Успешные обработки | какая доля сообщений дошла до результата |
| Повторы | как часто система восстанавливается после временных ошибок |
| Очередь ошибок | сколько элементов требуют человека |
| Возраст самого старого сообщения | есть ли накопившийся хвост |
| Сверка итогов | совпали ли записи, суммы и количества за одинаковый период; одни общие итоги могут скрыть взаимно компенсирующиеся ошибки |
Таблицу можно прокрутить вбок →
Если ваша проблема проще - люди вручную переносят поля между двумя системами - начните с карты ручного ввода. Очереди и событийная архитектура нужны тогда, когда масштаб и цена сбоя действительно этого требуют
Источники и границы выводов
Три таблицы и вопросы выбора - авторская схема разбора интеграции. Возможности и гарантии конкретного сервиса обмена нужно сверять с его документацией и настройками
- AWS Prescriptive Guidance: Asynchronous communication - официальная документация по асинхронному взаимодействию. Поддерживает рекомендации по подтверждению приёма, обработке дублей, повторным попыткам, очередям ошибок и наблюдаемости; не является гарантией надёжности конкретной интеграции
