Чем синхронная интеграция отличается от асинхронной? Когда нужны очереди сообщений?
Короткий ответ
- Синхронно: вызывающий ждёт ответ в том же запросе
- Асинхронно: запрос принят, результат приходит позже
- Очередь буферизует нагрузку и развязывает системы
- Падение получателя не роняет отправителя
- Брокеры: RabbitMQ, Kafka; паттерны публикация-подписка
- Плата за асинхронность: сложнее отладка и согласованность
- Выбор от требований: нужен ли ответ немедленно
Синхронная интеграция проще, но связывает доступность систем, асинхронная через очереди развязывает их и сглаживает нагрузку ценой итоговой согласованности и усложнения отладки.
Как сказать вслух
пример ответаПри синхронной интеграции вызывающая система отправляет запрос и ждёт ответ здесь и сейчас — как обычный REST-вызов. При асинхронной она отправляет сообщение и продолжает работать, а результат придёт позже — через очередь или колбэк. Очереди нужны, когда системы не должны зависеть от доступности друг друга, когда нагрузка неравномерная и её нужно сглаживать, или когда одно событие должны получить несколько потребителей. Плата — сложнее отладка и данные согласуются не мгновенно, а в итоге.
Подробный ответ
Основной ответ
Синхронная интеграция: вызывающая сторона блокируется до получения ответа (типично REST/gRPC). Плюсы — простота и немедленный результат; минусы — связность по доступности и времени ответа: если приёмник упал или тормозит, страдает вызывающий, а каскад таких вызовов снижает общую надёжность. Асинхронная: отправитель публикует сообщение и не ждёт; доставку обеспечивает брокер (RabbitMQ, Kafka) по паттернам «точка-точка» или «публикация-подписка». Очередь даёт развязку систем, буферизацию пиков, повторную доставку, нескольких независимых потребителей событий. Цена — итоговая согласованность (eventual consistency), необходимость обрабатывать дубли (идемпотентность потребителя), очереди недоставленных сообщений (DLQ), сложная сквозная трассировка. Аналитик выбирает по требованию бизнеса: нужен ли результат в момент операции (проверка остатка при оформлении) или достаточно гарантированной доставки (отправка чека, синхронизация справочников).
Ключевые моменты
- Критерий выбора. Если бизнес-операция не может завершиться без ответа второй системы — синхронно; если достаточно гарантии «будет обработано» — асинхронно.
- Гарантии доставки. At-most-once, at-least-once, exactly-once; на практике чаще at-least-once, поэтому потребитель обязан быть идемпотентным.
- DLQ и ретраи. Необработанные сообщения уходят в очередь мёртвых сообщений с алертингом — аналитик описывает этот сценарий в требованиях.
- Eventual consistency. Данные в системах сходятся с задержкой; нужно явно согласовать с бизнесом допустимое окно рассинхронизации.
Практический контекст
Это один из главных вопросов на позицию системного аналитика по интеграциям. Интервьюер даёт кейс — «заказ создан, нужно уведомить склад, бонусную систему и аналитику» — и ждёт обоснованного выбора асинхронной публикации события. Сильный кандидат сам упоминает обработку дублей, DLQ и вопрос к бизнесу о допустимой задержке данных; слабый выбирает способ по принципу «Kafka — это модно».
Частые ошибки
- Выбирают асинхронность «для надёжности», не умея объяснить обработку дублей и сбоев
- Забывают, что at-least-once означает возможные повторы и требует идемпотентного потребителя
- Не согласуют с бизнесом допустимую задержку синхронизации данных