День 2466. #ВопросыНаСобеседовании
Оптимизировал Тормозящий Микросервис и Шокировал Интервьюера
Техническое собеседование проходило как любое другое. Стандартные вопросы и страх, что спросят о чём-то, с чем ты работал года 2 назад. А потом прозвучал убийственный вопрос: «Один из микросервисов работает очень медленно из-за внешних вызовов API. Как его оптимизировать?»

Хм… Это не про заученный алгоритм и не про архитектуру. Надо размышлять как опытный бэкенд.

1. Без паники, сначала диагностика
Каждый интервьюер ожидает, что вы сразу перейдёте к «кэшированию» или «параллельным вызовам». Но я сказал: «Сначала я проверю, действительно ли внешний API является узким местом». Интервьюер приподнял бровь.

Я пояснил. Добавим трассировку (Open Telemetry) для отслеживания длительности каждого внешнего вызова. Посмотрим задержки для каждой зависимости (иногда медленные наша сериализация или парсинг JSON). Посмотрим на 95-й и 99-й процентили времени отклика, т.к., если 1 из 100 вызовов занимает 5 секунд, этого достаточно, чтобы сервис казался медленным. Проверим закономерности повторных попыток. Если API нестабилен и наш сервис повторяет запрос по три раза, мы утраиваем время отклика.

Цель не в том, чтобы исправить ошибку, а в том, чтобы доказать, что я не исправляю её вслепую. Интервьюер кивнул.

2. Оптимизаций на стороне клиента
Если внешний API действительно медленный, перейдём к улучшениям на клиенте:
- Установим разумные тайм-ауты (2–3 секунды), в зависимости от SLA, и быстрый выход при таймауте.
- Настроим повторные попытки с экспоненциальной задержкой и ограничим количество повторных попыток, например: 1 – через 200 мс, 2 – через 400мс, 3 – через 800мс. Если ответа нет – выходим.
- Добавим «выключатель» (Circuit Breaker). Если API продолжит давать сбои, прервём попытки. Нет смысла долбить сломанную конечную точку.

3. Параллелизм и асинхронные вызовы
Вместо последовательного выполнения нескольких внешних вызовов, распараллелим их, используя асинхронные шаблоны вроде класса Parallel или Task.WhenAll(). Теперь общее время всех запросов будет близко к времени самого медленного, а не к сумме всех.

4. Кэширование
Если данные из внешнего API меняются нечасто, кэшируем их. Можно использовать кэш в памяти, распределённый или гибридный и кэшировать ответы, например, на 10 минут, чтобы кэш достаточно часто обновлялся. Когда API недоступен, можно выдавать слегка устаревшие данные из кэша. Но здесь важно настроить стратегии инвалидации, отслеживать утечки памяти и соотношение попаданий и промахов.

5. Пакетирование и агрегация
Возможно, внешний API поддерживает пакетные запросы, так что можно делать 1 запрос вместо нескольких, например, отправлять несколько идентификаторов в одном запросе. Либо периодически скачивать все данные из API и использовать их локально.

6. Пересмотр архитектуры
Если сервис слишком сильно зависит от внешних API, можно рассмотреть событийно-ориентированную архитектуру. Вместо вызова API в реальном времени обрабатывать данные асинхронно через очереди сообщений (Kafka или RabbitMQ). Так основной поток будет реагировать быстро, а фоновые процессы будут извлекать или обновлять внешние данные позже.
Можно внедрить API Gateway, кэширующий или объединяющий несколько ответов внешнего API. Тогда наш микросервис будет обращаться к одной оптимизированной конечной точке вместо десяти разных.

7. Плавная деградация
Иногда нужно просто корректно завершить работу:
- Установить тайм-аут и возвращать кэшированные/резервные данные.
- Регистрировать инциденты, но не допускать сбоя в работе.
Пользователям всё равно, какой API дал сбой. Им важно, чтобы приложение работало.

8. Мониторинг
Добавим метрики, будем отслеживать задержку по каждой зависимости, оповещать о резком увеличении времени отклика, следить за закономерностями при замедлениях.

После того, как я закончил, интервьюер помолчал. А потом сказал: «Да… как-то так мы и решили эту проблему».

Источник: https://blog.stackademic.com/interviewer-i-optimized-a-laggy-microservice-and-shocked-my-interviewer-heres-what-i-did-562cd8f0dcee
Автор оригинала: Shanvika Devi