Какие паттерны микросервисов использовались, например саги, apigateway

Что проверяют

Работали ли вы с распределёнными транзакциями на практике или знаете паттерны по статьям. Вопрос про опыт, поэтому следом спросят детали: как делали компенсацию, что было при повторной доставке сообщения, где жила авторизация.

Как отвечать

Рассказывайте на своём проекте: задача, паттерн, почему именно он. Опорные темы:

• Saga: цепочка локальных транзакций, у каждого шага есть компенсирующее действие. Хореография: сервисы реагируют на события друг друга через Kafka или NATS, связность ниже, но поток трудно проследить. Оркестрация: координатор ведёт процесс, в Go для этого берут Temporal с его Go SDK или конечный автомат на таблице состояний;
• Transactional outbox: событие пишется в таблицу outbox в той же транзакции, что и данные, а отдельный процесс или Debezium публикует его в брокер. Иначе событие теряется при падении между коммитом и отправкой;
• идемпотентные потребители: доставка «хотя бы один раз», поэтому обработчик помнит идентификаторы обработанных сообщений;
• API Gateway: единая точка входа, маршрутизация, проверка JWT, rate limiting, TLS. Из мира Go это KrakenD и Traefik, также встречаются Envoy и Kong. Вариант BFF: свой шлюз под каждый тип клиента;
• устойчивость: таймауты через context.WithTimeout, ретраи с экспоненциальной задержкой и джиттером, circuit breaker (sony/gobreaker).

Если саги вы не внедряли, скажите прямо и разберите, как спроектировали бы оформление заказа: резерв товара, оплата, доставка и компенсация на каждом шаге.

Где спотыкаются

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

Публикуют событие после коммита без outbox. На вопрос «что будет, если сервис упадёт между этими строками» ответа нет.

Кладут бизнес-логику в API Gateway. Шлюз разрастается в новый монолит, через который проходит каждый релиз.