Какое взаимодействие между сервисами предпочтительнее: синхронное или асинхронное
Что проверяют
Не поддадитесь ли вы на формулировку с ложным выбором. Правильный ответ начинается с «зависит», но дальше нужны критерии, а не слова про гибкость. Следом обычно просят разобрать конкретный сценарий: оформление заказа, отправка уведомления, списание денег.
Как отвечать
Разложите выбор по свойствам, а не по вкусу:
- синхронный вызов: HTTP или gRPC, когда результат нужен прямо сейчас, чтобы ответить пользователю. Плюс это простая отладка. Минус это временная связность: доступности перемножаются, задержки складываются, недоступный сервис роняет цепочку целиком;
- асинхронный обмен: Kafka, NATS, RabbitMQ, когда вызывающему ответ не нужен. Событие переживёт недоступность потребителя, всплеск нагрузки сгладит очередь, нового подписчика добавляют без правок издателя. Плата это отложенная согласованность и сложный разбор инцидентов;
- правило выбора: то, результат чего пользователь ждёт на экране, идёт синхронно, побочные эффекты (письма, аналитика, индексация) уезжают в события. Согласованность через несколько сервисов делается сагой, а не распределённой транзакцией.
Конкретика нужна в обе стороны. В синхронной части это context.WithTimeout, ограниченные повторы с экспоненциальной паузой и джиттером, размыкатель цепи, лимит одновременных запросов. В асинхронной это доставка минимум один раз, а значит идемпотентность потребителя по ключу сообщения, порядок только внутри партиции, очередь недоставленных сообщений и мониторинг отставания.
Ценят и такой пункт: запись в базу и отправку события нельзя выполнить атомарно двумя вызовами, для этого есть transactional outbox с отдельным отправителем.
Где спотыкаются
Отвечают, что асинхронное лучше, оно быстрее и надёжнее. Быстрее становится ответ вызывающему, сквозное время до результата обычно растёт, а вместо явного сбоя вы получаете копящееся отставание.
Путают внутрипроцессную асинхронность с межсервисной. Горутина с каналом это не асинхронное взаимодействие сервисов: упал процесс, и задача исчезла, потому что нигде не сохранилась.
Забывают про повторную доставку. Брокер гарантирует «хотя бы один раз», и потребитель без ключа идемпотентности однажды спишет деньги дважды.