Backend-разработчик

1. Оптимизация поиска (ElasticSearch)
При поиске товара в результате пользователю отдавались не релевантные товары – CTR на первый результат составлял 45%. Данные в индексе обновлялись раз в 15 минут cron-jobой, поэтому
новый товар появлялся в поиске с задержкой. P95 latency – 1 секунда при CPU ElasticSearch 85% на 2.5K RPS.

Решение и результат:
1. Улучшил релевантность поиска в ElasticSearch: настроил веса полей, добавил boost по популярности, fuzzy matching и транслитерацию, в итоге CTR вырос в полтора раза (45% -> 68%), доля запросов без результатов сократилась вдвое, клиенты стали точнее находить нужные товары, конверсия поднялась на 12%.
2. Внедрил CDC через Kafka Connect + расширение search-service – данные в поиске обновляются за 10 секунд вместо 15 минут, убрал cron-job для full reindex, снизил нагрузку на PostgreSQL.
3. Профилировал ES через Profile API – добавил кеширование популярных запросов, оптимизировал connection pooling, перешёл на filter context. P95 latency упала с 1s до 300ms, нагрузка на CPU снизилась вдвое.
4. Добавил каскадный fallback при нулевых результатах – доля запросов без результатов сократилась вдвое (8% → 4%).

2. Оптимизация ClickHouse для аналитики
Аналитики, маркетологи, PM и др. работали с ClickHouse напрямую или через Grafana, но запросы выполнялись по 10–20 секунд. Kafka lag периодически вырастал до 50K+ сообщений, статистика зависала. Разработчик, который строил платформу, ушёл, и система осталась без поддержки.

Решение и результат:
1. Оптимизировал схему данных в ClickHouse, подготовил materialized views для выгрузки аналитики — данные стали читаться в 9-12 раз меньше, latency упала с 8 секунд до 750ms.
2. Переписал обработку событий на batch processing — throughput вырос в 5 раз, kafka lag упал практически до нуля. Теперь аналитики, маркетологи, менеджеры видят статистику в real-time без сбоев.
3. Переключил compression с ZSTD на LZ4 — данные стали читаться меньше.

Инструменты: Go (1.25 – 1.26), Echo, gRPC/protobuf, PostgreSQL, Redis, Kafka, Docker, Kubernetes, Prometheus, Grafana, ClickHouse, ElasticSearch, OpenTelemetry, Jaeger

Создание сервиса доставки и расчёта ETA.
PHP-монолит не справлялся с ростом нагрузки: при масштабировании latency вырастала до 1,5–2s. Горизонтально масштабировать отдельные части было невозможно, приходилось поднимать весь монолит. ETA для пользователей не было вовсе, курьер просто приезжал «когда-то».

Решение и результат:
1. Вынес из legacy монолита сервис расчета доставки и ETA в микросервис на Go – задержка обработки снизилась с 1-1,5 секунд до 400 мс.
2. Интегрировал Yandex RouteQ: добавил статический ETA через Planning API при оформлении заказа, реализовал динамический пересчёт (Track & Trace) – 85% доставок вовремя.
3. Внедрил кеширование в Redis для данных по ETA, реализовал fallback на PostgreSQL при падении Redis.
4. Настроил алерты в Prometheus Alertmanager с разграничением на critical/warning – время реагирования на инциденты снизилось в 5 раз.
5. Перевёл сервис на микросервисную архитектуру, участвовал в миграции с PHP на Go.

Инструменты: Go, Echo, gRPC/protobuf, PostgreSQL, MongoDB, Redis, Kafka, Docker, Kubernetes, Prometheus, Grafana