Пользователи сервиса N иногда оставляют ЭЦП (усиленную, квалифицированную). Для проверки подлинности этой ЭЦП используется сервис check-sign, который часть проверки осуществляет с помощью сервиса nalog.ru. Схематично взаимодействие представлено ниже:
- microservice N взаимодействует с check-sign через сообщения в kafka. Топик "check-sign" - запрос на проверку, "success" - успешная проверка, "fail" - неуспешная
- сервис check-sign для отказоустойчивости развернут в 3 репликах. количество под может быть автоматически увеличено под нагрузкой
- взаимодействие check-sign и nalog.ru - через REST API, другие способы интеграции отсутствуют
Проблемой является периодическая недоступность сервиса nalog.ru. Требуется реализовать возможность накопить сообщения и, когда сервис восстановится, закончить проверку.
Необработанные подписи складываются в БД. Внешний шедулер периодически вызывает запрос на "переотправку" проблемных подписей.
Минусы
- Очередь может разгребать только 1 инстанс check-sign
- Если вызывать слишком часто - 2 инстанса начнут обрабатывать одну и ту же подпись
Необработанные подписи отправляются в топик DLQ. Из этого топика чтение происходит с задержкой и пачками по N записей.
Минусы
- Еще один топик
- Если сервис восстановится - разбор очереди будет медленный
Необработанные подписи возвращаются в тот же топик. Чтобы не попасть в бесконечный цикл, на сервисе check-sign необходимо реализовать предохранитель
Минусы
- Придется кодить предохранитель