resilience

4 posts

Ваш цикл повторов предполагает, что первый запрос не удался. Скорее всего, это не так.

Таймаут или сбой не означают, что ваш API-запрос был потерян. Вот как ключи идемпотентности делают повторы безопасными, и как паттерн хранения на самом деле предотвращает дублирование.

Ваш сервис падает на полпути при обработке запроса . Клиент видит таймаут и повторяет запрос. Теперь у вас два списания. Клиент злится. База данных…

Блокировка, которая переживает ваш процесс: как на самом деле работают distributed lease

In-memory mutex исчезает при перезапуске сервера. Вот как distributed lease с fencing token и TTL предотвращают дублирование работы при сбоях, и где они всё ещё ломаются.

Ваш не переживает . Он не переживает OOM, deployment rollout и перезагрузку узла. В тот момент, когда процесс завершается, lock пропадает. Если этот lock…

Circuit breaker без goroutine, таймеров и фоновой нагрузки

Большинство библиотек circuit breaker порождают фоновые потоки для проверки восстановления. Они вам не нужны. Вот request-driven дизайн, который устраняет всю фоновую нагрузку без потери корректности.

Каждый production circuit breaker, который я рассматривал, рано или поздно порождает фоновый поток. Это может быть Go goroutine, Java или Rust tokio task.…

У вашего веб-сервиса есть путь корректного завершения. Это и есть баг.

Crash-only софт обрабатывает каждый сбой как крах, а каждый запуск — как восстановление. Для веб-сервисов это означает удаление логики завершения и проектирование состояния, которое переживёт kill -9.

У вашего веб-сервиса есть обработчик завершения. Он сбрасывает буферы, закрывает соединения, записывает чекпоинты. Вы тестировали его раз, может быть. В…