Расскажи о самом сложном баге, который ты чинил за последние полгода.

Баг и его последствия

За последние полгода самый сложный баг, с которым я столкнулся, это была race condition в нашей распределённой системе обработки платежей, из-за которой примерно 0,1% транзакций обрабатывались дважды. Это было особенно сложно, потому что происходило только при определённых условиях высокой нагрузки и было почти невозможно воспроизвести в нашей staging-среде. Баг имел серьёзные бизнес-последствия — подрывал доверие клиентов и создавал расхождения в бухгалтерии на тысячи долларов.

Подход к расследованию

Я начал с анализа наших дашбордов мониторинга и заметил, что дублирующиеся транзакции кластеризовались вокруг всплесков трафика. Потом я:

• Собрал логи из нескольких микросервисов, участвующих в процессе платежа
• Использовал distributed tracing, чтобы коррелировать события между сервисами
• Проанализировал временны́е паттерны между дублирующимися транзакциями — в среднем 200–500 мс друг от друга
• Настроил нагрузочное тестирование, которое могло симулировать уровень конкурентности из продакшена

Проблема была в том, что стандартные техники дебага не работали — баг исчезал, когда я добавлял логирование, из-за изменения тайминга выполнения.

Анализ корневой причины

После трёх дней расследования я обнаружил, что проблема была в нашей логике проверки idempotency key. Когда два платежа с одинаковым idempotency key приходили почти одновременно:

Наша Redis-based проверка idempotency имела зазор между операциями чтения и записи. При нормальной нагрузке это окно было незначительным, но во время всплесков трафика оно становилось достаточно большим, чтобы спровоцировать race condition.

Реализация решения

Я реализовал distributed lock с помощью Redis-команды SET NX с автоматическим истечением:

• Перешёл с check-then-set на атомарный set-if-not-exists
• Добавил нормальную обработку таймаутов, чтобы не допустить дедлоков
• Реализовал retry-логику с exponential backoff для легитимных конкурентных запросов
• Добавил подробные метрики для мониторинга времени получения лока и ошибок

Я также поработал с QA-командой, чтобы написать специализированный нагрузочный тест, который мог надёжно воспроизвести race condition и подтвердить, что исправление работает корректно.

Результаты и выводы

После деплоя исправления мы две недели мониторили систему и подтвердили ноль дублирующихся транзакций даже при пиковых нагрузках. Этот опыт научил меня нескольким важным вещам:

• Проектировать с учётом конкурентности с самого начала, особенно в распределённых системах
• Понимать, что race conditions требуют других стратегий дебага, чем детерминированные баги
• Создавать воспроизводимые тест-кейсы для проблем, зависящих от тайминга
• Ценить комплексную observability в продакшен-системах

Я также задокументировал этот паттерн и рассказал о нём команде, что привело нас к аудиту других критических путей и помогло заранее предотвратить похожие проблемы.