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

Задача: Разработка ядра высоконагруженного микросервиса для обработки финансовых транзакций с требованием к пропускной способности >10k TPS (транзакций в секунду) и гарантированной идемпотентной обработкой.

Ключевые технические решения и сложности:

1. Реактивная архитектура для масштабирования:

   • Использован Spring WebFlux (на основе Project Reactor) для неблокирующего I/O и эффективного использования потоков при высокой конкуренции.

   • Это позволило обрабатывать тысячи одновременных соединений на небольшом количестве потоков.

     @RestController
     @RequiredArgsConstructor
     public class TransactionController {
     private final TransactionService transactionService;
     
     @PostMapping("/transactions")
     public Mono<TransactionResponse> process(
             @RequestBody Mono<TransactionRequest> requestMono,
             @RequestHeader("Idempotency-Key") String idempotencyKey) {
         return requestMono
             .flatMap(request -> transactionService.processIdempotent(request, idempotencyKey))
             .timeout(Duration.ofMillis(800)) // Жесткий SLA
             .onErrorResume(TimeoutException.class, e -> 
                 Mono.just(TransactionResponse.failed("TIMEOUT")));
     }
     }

2. Механизм идемпотентности:

   • Реализован паттерн "Idempotency Key". Каждый запрос клиента содержит уникальный ключ.
   • При первом получении ключа результат операции кешируется в Redis с TTL.
   • Повторный запрос с тем же ключом возвращает кешированный результат, предотвращая дублирование операций (например, списания средств).

3. Оптимизация работы с базой данных:

   • Для массовой вставки событий использованы batch-операции (JDBC batching) и асинхронные драйверы.
   • Критичные для чтения данные (балансы, статусы) кешировались в Redis с стратегией Cache-Aside.

4. Надежность и мониторинг:

   • Интеграция с Micrometer и Prometheus для сбора метрик (латентность, ошибки, rate).
   • Реализован circuit breaker (Resilience4j) для вызовов внешних платежных шлюзов.
   • Все бизнес-события записывались в лог структурированно (JSON) для последующего анализа в ELK-стеке.

Результат: Сервис стабильно обрабатывал пиковые нагрузки, средняя задержка (latency) составила <100 мс на 95-м перцентиле. Механизм идемпотентности полностью исключил дублирующие финансовые операции.