Как улучшить работу с REST запросами в сервисе кэшбэка

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

Умеете ли вы искать узкое место, прежде чем предлагать решения, и знаете ли инструменты Java-стека для межсервисных вызовов. Следом обычно просят конкретику: какой клиент, какие таймауты и что будет, если API партнёра лёг.

Как отвечать

Начните с вопроса, что именно плохо: задержка, ошибки или нагрузка. Метрики клиента через Micrometer (p95 и p99 времени ответа, доля 5xx и таймаутов) и трейсинг покажут, какой вызов в цепочке тормозит.

Дальше меры по слоям:

• HTTP-клиент: RestClient (Spring 6.1+) или WebClient вместо RestTemplate, который давно в режиме поддержки. Пул соединений с явными лимитами и отдельные connect- и read-таймауты: у многих клиентов по умолчанию ожидание не ограничено;
• параллельность: независимые запросы (баланс, правила начисления, профиль) выполнять одновременно через CompletableFuture со своим пулом или на виртуальных потоках Java 21;
• кеш: правила кэшбэка и справочник партнёров меняются редко, их держат в Caffeine или Redis с TTL. Баланс пользователя так кешировать нельзя;
• устойчивость: Resilience4j, circuit breaker на внешние API, retry с экспоненциальной задержкой только для идемпотентных вызовов;
• идемпотентность: начисление кэшбэка это деньги. Ключ идемпотентности (заголовок Idempotency-Key или id транзакции) защищает от двойного начисления при повторе;
• асинхронность: начисление по событию покупки лучше вынести в очередь (Kafka), а не делать синхронным звеном в цепочке оплаты.

Про API самого сервиса: пагинация вместо выдачи всей истории операций, сжатие ответов, внятные коды (409 на дубль, 429 на превышение лимита).

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

Сыплют списком «кеш, асинхронность, мониторинг» без привязки к проблеме. Интервьюер ждёт, что вы сначала спросите, где болит.

Ставят retry на неидемпотентный POST начисления. Если оборвался ответ, запрос мог пройти, и повтор начислит кэшбэк дважды.

Кешируют всё подряд и не думают об инвалидации: после покупки пользователь видит старую сумму и пишет в поддержку.