Мониторинг изменений контрагента через API: архитектура без пропущенных событий

Разделите полный снимок и поток изменений

При постановке компании на наблюдение сохраните исходный снимок нужных реквизитов и состояние проверки. Дальше API изменений должен сообщать, что именно поменялось с прошлого обработанного курсора, а не заставлять систему бесконечно сравнивать все поля всех компаний.

У каждого объекта наблюдения должны быть устойчивый идентификатор, дата постановки, набор интересующих типов событий и владелец реакции. ИНН удобен для поиска, но модель нужно сверять с идентификаторами и методами конкретного API.

• Исходный снимок
• Стабильный идентификатор
• Курсор или отметка последней обработки
• Типы интересующих изменений
• Владелец реакции

API отдаёт данные, но не заменяет бизнес-решение; сначала опишите ручной регламент проверки контрагента, а затем автоматизируйте сбор фактов и выделение сигналов.

Считайте повтор события нормальным состоянием

Сеть, таймаут или перезапуск обработчика могут привести к повторному получению одного изменения. Поэтому ключ события или комбинация объекта, типа и версии должны защищать бизнес-действие от дубля.

Курсор обновляйте только после успешной фиксации события и постановки нужной задачи. Иначе сбой между чтением и обработкой создаст тихий пропуск, который трудно восстановить задним числом.

• Идемпотентный ключ
• Транзакционное сохранение
• Повтор с увеличивающейся задержкой
• Отдельная очередь ошибок
• Метрика возраста необработанного события

Планируйте обход после простоя заранее

Официальное описание API Фокуса указывает, что история изменений в новом мониторинге хранится ограниченный период. Значит, длительный простой нельзя лечить бесконечным чтением старого курсора: системе нужен сценарий повторного снимка и сверки.

Контрольная задача должна регулярно проверять, когда обработчик в последний раз успешно дочитал поток, сколько объектов наблюдается и не приближается ли разрыв к пределу хранения истории.

• Дата последнего успешного чтения
• Глубина доступной истории
• Повторный снимок после длинного простоя
• Сверка числа объектов
• Аварийное уведомление владельцу

Не превращайте каждое изменение в красную тревогу

Техническое событие должно преобразовываться в понятное бизнес-действие. Смена адреса может потребовать проверки договора, новое дело — оценки юристом, изменение реквизитов — независимой сверки перед платежом. Некоторые обновления достаточно сохранить без уведомления.

Для каждого класса задайте приоритет, получателя, срок и условие закрытия. Тогда мониторинг измеряется не количеством сигналов, а долей своевременно обработанных значимых изменений.

• Класс события
• Приоритет
• Ответственная роль
• Срок реакции
• Проверяемый результат