Перейти на PRO

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

Тип вопроса: Софт-скиллы Вероятность: 10% Категория: Java Разработчик

Ответ

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.

Ответ 18+ 🔞

А, ну это же классика, блядь! Сидишь такой, пыхтишь над очередным «высоконагруженным микросервисом», а в голове один вопрос: «Ну и нахуя я в это влез?». Ладно, разбираем по косточкам, как есть.

Первый номер программы — финансовый цирк на трапеции.

Цель — сделать так, чтобы API по приёму бабла не сдохло, когда на него навалится тысяча запросов в секунду. Стек — стандартный джентельменский набор для самоистязания: Spring Boot, Кафка, Постгрес, Редис, и вся эта хуйня в докере, который потом в кубере.

Ключевые решения, ага, «решения». По факту — как не обосраться.

  • Асинхронщина. Главный принцип — «принял и забыл». Пользователь шлёт платеж, мы ему быстро-быстро говорим «окей, принял, иди нахуй», кладём запись в базу со статусом PENDING (типа «висит, блядь»), а потом пингуем в Кафку событие «ёпта, тут бабло пришло, разберись». Отдельный консьюмер этот пиздец ловит и уже в своём, неспешном темпе, обрабатывает. Красота, пользователь не ждёт, а система не падает. Идиллия, ёпта.
  • Идемпотентность. Это чтобы какой-нибудь умник не отправил один и тот же платеж сто раз, потому что у него интернет заглючил. Берём от клиента idempotency-key (уникальный ключик, как от сейфа) и если видим его повторно — просто отдаём старый ответ. Без повторной обработки. «О, я это уже видел, пошёл нахуй со своим дубликатом».
  • База данных. Тут начинается настоящая магия, потому что Постгрес — он хоть и хорош, но если его неправильно попросить, он такую песню споёт о перформансе, что волосы дыбом встанут. Шардирование по дате, чтобы в одной таблице не скопилось данных за десять лет. Индексы на status, created_at, user_id, чтобы не делать full scan, блядь, таблицы на миллиард записей. Уровень изоляции READ COMMITTED и оптимистичные блокировки — это такой тонкий баланс между «всё должно быть точно» и «но нам ещё и быстро надо». Ходишь по лезвию, сука.
  • Отказоустойчивость. Это когда ты заранее знаешь, что всё ебнется, и готовишь план «Б». В код натыканы аннотации, как новогодняя ёлка игрушками: @CircuitBreaker (чтобы если сервис-получатель сдох, не долбить его труп), @RateLimiter (чтобы самих себя не положить), @Retry (ну вдруг с первого раза не получилось, дадим ещё пару попыток, авось пронесёт). И fallback метод, который в случае полного пиздеца просто скажет «всё ок, платеж в обработке», даже если на самом деле всё уже горит синим пламенем. Лишь бы клиент успокоился, хитрая жопа.
// Код не трогаем, он и так прекрасен в своей строгости.
  • Мониторинг. Без этого — как в танке без смотровых щелей. Метрики: сколько обработали, сколько упало, сколько времени всё это безобразие заняло. Всё это летит в Prometheus, а потом в Grafana рисуются красивые графики, на которые начальство смотрит и говорит «о, зелёная линия идёт вверх, хорошо». А когда линия падает — тебе на телефон приходит алерт, и ты, блядь, в три часа ночи понимаешь, что пора воевать.

Второй акт — логистический ад на колёсах.

Тут нужно было считать маршруты для курьеров. Задача — чтобы парень не ехал через всю Москву за одной посылкой, а потом обратно за второй.

  • Геоданные. Хранить широту/долготу в обычном поле — это путь в никуда. Поэтому PostGIS, специальный тип GEOMETRY и магические запросы вроде ST_DWithin, которые за секунду находят все точки в радиусе 500 метров. Без индекса GIST это работало, блядь, минуты. С индексом — мгновенно. Вот что значит правильный инструмент, ёпта.
  • Кэш маршрутов. Понимаешь, запрос к Google Maps API — он платный и не мгновенный. А считать маршрут от метро «Охотный Ряд» до Кремля — запрос, который повторяется сто раз на дню. Так зачем каждый раз стучаться к дяде Гуглу? Рассчитали один раз — засунули результат в Redis с ключом-хэшом от координат. Следующий запрос — бац, и ответ уже готов. Экономия денег и нервов — овердохуища.
  • Service Discovery (Eureka). Это чтобы когда у тебя пять инстансов сервиса маршрутов, и один из них накрылся медным тазом, остальные четыре даже не заметили, а запросы пошли к живым. И чтобы можно было добавить шестой инстанс, не переписывая конфиги у всех остальных сервисов. Умно, блядь.
  • WebSocket. Чтобы не опрашивать сервер каждые пять секунд «а есть чё новенькое?», а получать уведомления о новом заказе прямо в приложение, как сообщение в телеге. «Ваня, тебе новый пакет в двух кварталах, пиздуй».

И, наконец, финальный трюк — расчленёнка монолита.

Представь: есть старый, жирный, вонючий монолит, который работает, но все его ненавидят. Его нельзя убить, но из него нужно вытащить модуль отчётов, не остановив при этом весь бизнес. Стратегия — Strangler Fig («Фикус-душитель»). Звучит угрожающе, так оно и есть.

  1. Инкапсуляция. Сначала ты внутри этого монстра аккуратно, как сапёр, отгораживаешь модуль отчётов. Делаешь из него отдельную библиотеку, но пока она живёт внутри. Главное — провести чёткие границы, чтобы он ни за что лишнее не цеплялся.
  2. Дублирование трафика. Потом ставишь NGINX или другой роутер и начинаешь тихонько, по 1% трафика, скидывать запросы на отчёты в твой новенький, чистенький микросервис. А сам сидишь и сравниваешь логи: ага, в старом ответ такой, в новом — сякой. Если где-то расхождение — волнение ебать, ищешь баг.
  3. Синхронизация данных. Пока ты тестируешь, данные в монолите меняются. Чтобы твой микросервис не отстал от жизни, настраиваешь Debezium (CDC). Он как шпион сидит в логах базы монолита и стримит все изменения в базу микросервиса. Данные живые, всё в ажуре.
  4. Отключение. Когда 100% трафика уже ходит в микросервис, и неделю всё работает как часы, наступает момент истины. Ты заходишь в код монолита, находишь этот модуль, вычёркиваешь его, как позорного родственника, и выкидываешь. Выключаешь репликацию. Всё. Монолит похудел, микросервис живёт своей жизнью.

Главный пиздец во всём этом — не устроить коллапс данных, пока идёт миграция, и не сломать обратную совместимость. Один неверный шаг — и ты уже не герой, а тот, кто «положил продакшн в три часа дня». Стыд и срам. Поэтому тут нужна не скорость, а, блядь, терпение и проверка всего по десять раз.

© ХакСобесов, 2026
support@hacksobesov.com