Опишите технические детали и ключевые решения в ваших последних проектах.

1. Высоконагруженный микросервис для обработки финансовых транзакций

• Цель: REST API для асинхронной обработки платежей (>1000 TPS).
• Стек: Spring Boot, Apache Kafka, PostgreSQL, Redis, Docker, Kubernetes.
• Ключевые решения:
  • Асинхронная архитектура: Принятие платежа → сохранение в статусе PENDING → отправка события в Kafka → обработка в отдельном консьюмере → обновление статуса.
  • Идемпотентность: Все операции с платежами идемпотентны за счет уникального idempotency-key от клиента.
  • Производительность БД:
    • Шардирование таблиц по дате.
    • Индексы по полям status, created_at и user_id.
    • Использование READ COMMITTED уровня изоляции и оптимистичных блокировок для баланса целостности и скорости.
  • Отказоустойчивость:

    @RestController
    @Slf4j
    public class PaymentController {
        @PostMapping("/payments")
        @CircuitBreaker(name = "paymentService", fallbackMethod = "processPaymentFallback")
        @RateLimiter(name = "paymentService")
        @Retry(name = "paymentService", fallbackMethod = "processPaymentFallback")
        public Mono<PaymentResponse> processPayment(@Valid @RequestBody PaymentRequest request) {
            // Основная логика
        }
        public Mono<PaymentResponse> processPaymentFallback(PaymentRequest request, Throwable t) {
            log.error("Fallback for payment: {}", request.getIdempotencyKey(), t);
            return Mono.just(PaymentResponse.pending()); // Возвращаем статус "в обработке"
        }
    }

  • Мониторинг: Метрики (обработки, ошибок, latency) выставлялись в Micrometer и отправлялись в Prometheus. Настроены алерты в Grafana.

2. Backend для мобильного приложения геолокационной логистики

• Цель: Расчет и оптимизация маршрутов для курьеров в реальном времени.
• Стек: Spring Cloud (Eureka, Config Server), PostgreSQL/PostGIS, Redis, Google Maps API.
• Ключевые решения:
  • Геопространственные данные: Хранение координат в PostGIS (тип GEOMETRY). Оптимизированные запросы для поиска ближайших точек (ST_DWithin, индексы GIST).
  • Кэширование маршрутов: Результаты расчетов маршрутов между частыми точками кэшировались в Redis с TTL. Ключ формировался как хэш от координат начала и конца.
  • Service Discovery: Использование Eureka для динамического обнаружения инстансов сервиса расчета маршрутов, что позволяло легко масштабировать нагрузку.
  • WebSocket (STOMP): Для push-уведомлений курьерам о новых заказах в их зоне.

3. Миграция legacy-монолита на микросервисную архитектуру

• Цель: Поэтапный вывод из монолита модуля отчетности без downtime.
• Подход: Strangler Fig Pattern.
• Ключевые шаги:
  1. Инкапсуляция: Выделение модуля в отдельный jar внутри монолита с четкими API-границами.
  2. Дублирование трафика: Настройка роутера (например, NGINX) для направления части запросов на отчетность в новый микросервис. Сравнение логов и результатов.
  3. Синхронизация данных: Использование Debezium (CDC) для потоковой репликации необходимых таблиц из монолитной БД в БД микросервиса.
  4. Отключение: После полного тестирования и переноса 100% трафика — удаление модуля из монолита и отключение репликации.
• Главный вызов: Поддержание консистентности данных во время переходного периода и обеспечение обратной совместимости API.