Без трассировки один медленный запрос в микросервисах превращается в спор между командами. Разбираем, как observability меняет архитектуру, где растёт стоимость телеметрии и что проверять до выхода в прод.
Три реплики сервиса не делают систему отказоустойчивой. Разбираем, почему приложение продолжает отдавать 502 после падения ноды, как база данных превращается в единую точку отказа и что измерять до выхода в прод.
Когда сервис принимает запросы быстрее, чем успевает их обрабатывать, очередь растёт до таймаутов и 502. Разбираем, как измерить обратное давление, ограничить поток и доказать эффект цифрами.
Платёж прошёл, склад зарезервировал товар, а доставка не создала отправление. В такой цепочке нельзя откатить уже выполненные действия одной командой: нужно спроектировать компенсации, идемпотентность и восстановление после частичного сбоя.
Сервис может вернуть старое состояние, дважды списать деньги или потерять событие даже при исправном коде. На ревью нужно проверять не отдельные транзакции, а инварианты, границы записи и поведение системы при сбоях.
Событийная архитектура редко падает из-за самого брокера. Проблемы начинаются на границах: партиции заканчиваются, потребители не успевают за потоком, повторная доставка меняет данные, а ретраи превращаются в лавину.
Сервисная граница — это не отдельный репозиторий и не контейнер в Kubernetes. Это место, где система делит данные, ответственность и цену сбоя. Разбираем, что происходит внутри вызова и где проходит рабочая граница.
Форк чужой библиотеки превращает маленький патч в отдельный продукт с собственной ответственностью. Разбираем, когда достаточно обёртки или pull request, а когда без форка не обойтись.
Плавающий сбой нельзя чинить повторным запуском теста. Разберите случайный порядок, гонки и фиксированные таймауты, затем перестройте код так, чтобы ошибка получала воспроизводимый сценарий и проверяемый результат.
Сервис работает в одиночном тесте, но под параллельными запросами начинает случайно отдавать 502, таймауты или ошибки базы. Разбираем, как воспроизвести сбой, найти первый отказавший слой и не перепутать симптом с причиной.
Плавающий баг появляется один раз на сотни запросов, исчезает под отладчиком и не повторяется на стенде. Разбираем, как устроена недетерминированность, что фиксировать и как превратить случайный сбой в воспроизводимый тест.
Сложный баг редко живёт в одной строке: чаще он возникает на стыке релиза, кеша, очереди и базы данных. Методика помогает сузить область поиска, собрать проверяемые факты и не чинить симптом вместо причины.