Сервис-сосед упал: что делать
Вопрос
Ваш сервис синхронно зависит от сервиса цен, который иногда тормозит и падает. Как вы сделаете интеграцию устойчивой?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Таймауты на подключение и чтение
Retry только для идемпотентных вызовов, с backoff и джиттером
Circuit breaker и fallback (кеш, значение по умолчанию)
Bulkhead: отдельный пул или лимит на зависимость
Метрики и алерты по ошибкам и состоянию breaker
Подумать об асинхронной интеграции или локальной копии данных
Что могут спросить следом
- Чем плох retry без circuit breaker?
- Где хранить кеш для fallback?
Разбор
Первое это таймауты на соединение и чтение, иначе медленный сосед съест все наши потоки. Второе: retry с экспоненциальной задержкой и джиттером, но только для идемпотентных запросов и временных ошибок, в одном месте цепочки. Третье: circuit breaker из Resilience4j, который при массовых ошибках перестаёт звать сервис и сразу отдаёт fallback, например последнюю известную цену из кеша, если бизнес это допускает. Четвёртое: bulkhead, ограничение параллельных вызовов к этой зависимости, чтобы она не заняла все потоки. Всё это под метриками Micrometer с алертами. И отдельно спрашиваю себя, нужна ли синхронная зависимость: часто цены можно получать событиями и держать локальную копию, тогда падение соседа нас вообще не задевает.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.