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

Отлично, крепкий каркас получился. Я бы посоветовал сделать шлюз в виде подключаемого модуля, чтобы он мог хранить кеш последних токенов авторизации в памяти — так будет меньше обращений для валидации. И, если перейдешь на Protobuf, сможешь чуть больше сжать полезную нагрузку и избавиться от накладных расходов заголовка "Content-Type". Для очереди повторов — тема Kafka с идемпотентными потребителями, это обеспечит идемпотентность системы без дополнительного состояния. Еще одна небольшая доработка: используй хук корректного завершения работы на каждом сервисе, чтобы "сливать" соединения при масштабировании — так мы не оборвем текущие запросы. Это должно помочь поддерживать низкую задержку и сохранить архитектуру чистой.

Отлично. Как только нарисуешь схему, запустим стресс-тест в самых крайних случаях: нагрузим шлюз, выбьем брокера и посмотрим, как сработает автоматический переключатель. Это даст нам подтверждение, что эта самая задержка в синхронизации, которую ты гонишь, действительно работает. Дай знать, как только схема будет готова, и тогда подкрутим метрики.