Опишите самую сложную техническую задачу в вашей практике и как вы ее решали.

Одной из самых сложных была задача оптимизации времени отклика критического API-метода с 2 секунд до <200 мс под высокой нагрузкой.

Проблема: Метод агрегировал данные из нескольких источников (основная БД, кэш Redis, внешний REST-сервис) и выполнял сложные in-memory вычисления. Профилирование выявило узкие места:

1. Последовательные (непараллельные) запросы к внешним сервисам.
2. N+1 запрос к БД в цикле.
3. Неэффективный алгоритм агрегации данных в памяти (O(n²)).

Решение и предпринятые шаги:

1. Параллелизация независимых операций: Использование CompletableFuture для одновременного вызова внешнего сервиса и чтения из Redis.

   CompletableFuture<ExternalData> futureExternal = CompletableFuture.supplyAsync(() -> externalService.call());
   CompletableFuture<CacheData> futureCache = CompletableFuture.supplyAsync(() -> cacheService.get());
   CompletableFuture.allOf(futureExternal, futureCache).join();

2. Исправление N+1: Замена цикла с отдельными запросами на один batch-запрос с WHERE IN (...) или использование JOIN на уровне БД.

3. Оптимизация алгоритма: Замена вложенных циклов на использование HashMap для поиска за O(1), что снизило сложность с O(n²) до O(n).

4. Введение многоуровневого кэширования: Добавлен локальный кэш (Caffeine) для часто запрашиваемых и редко меняющихся данных поверх Redis.

Результат: После всех оптимизаций среднее время отклика составило 150 мс, а пропускная способность (throughput) выросла в 10 раз. Задача заняла 3 спринта (6 недель) и потребовала глубокого анализа, работы с профилировщиком (Async Profiler) и тестирования под нагрузкой (JMeter).