Наблюдаемость, production-инциденты и дизайн для глобального масштаба

Твой платёжный API начинает возвращать 422 на 10% запросов POST /charge. Симптом появился после SDK release. Двойных списаний пока нет — но сигнал о клиентском баге, который без фикса их вызовет. Dashboard должен поймать это раньше, чем станет production-инцидентом.

Минимально жизнеспособный observability dashboard

Каждая production idempotency + retry система нуждается в шести метриках:

1. idempotency_key_total по outcome:

• new — первичные ключи (здоровый baseline)
• replay — успешные retry (ожидаемо при transient сбоях)
• in_flight (409) — конкурентные гоночные запросы
• mismatch (422) — клиент переиспользует ключ с другим намерением (сигнал бага)

Rate mismatch > 0.1% от total POST — pages on-call. Означает баг генерации ключей у клиентов.

2. retry_attempt_total по номеру попытки (1, 2, 3, 4+): Всплеск на attempt-3 предшествует outage на минуты — самые persistent клиенты уже платят цену underlying деградации до того, как она стала заметной пользователям.

3. retry_delay_seconds_bucket — гистограмма реальных задержек. Бимодальное распределение (много retry на 0с и на 30с) говорит, что jitter не применяется.

4. outbox_lag_seconds — насколько устарел outbox relay? Алерт на lag > 30с. Растущий lag означает сбой relay или downstream брокера.

5. dead_letter_queue_depth — алерт на рост. Растущий DLQ — постоянно падающий конвейер: накапливаются poison messages.

6. http_request_outcome по классу статуса — 2xx / 4xx / 5xx / timeout. Разрез 4xx / 5xx отличает клиентские баги от серверных сбоев.

Production failure stories

Stripe 2017: переключение idempotency-кеша с одного Redis-кластера на другой ненадолго потеряло in-flight ключи. Несколько двойных списаний. Stripe добавил Postgres как постоянный авторитетный backing store — Redis теперь только hot-path cache.

Knight Capital 2012: отсутствующий feature flag плюс агрессивные retry против биржевого фида превратили deploy-глитч в $440M непреднамеренных торгов за 45 минут. Корень: at-least-once без идемпотентных консумеров.

AWS S3 сентябрь 2017: внутренняя подсистема возвращала 500 во время outage. Агрессивные retry без jitter у клиентов усилили сбой по всему региону, пока AWS не опубликовал guideline по обязательному jitter.

GitHub 2018: failover базы потерял lease на outbox-relay. События копились в outbox 2 минуты, потом флашились разом — само-нанесённый thundering herd на стороне консумера. Митигация: rate-limit relay при catch-up (например, 500 событий/с) для сглаживания спайка.

Все истории об одном корне: at-least-once без идемпотентных консумеров ИЛИ retry без jitter.

Cross-protocol: HTTP, gRPC, Kafka

Концепция idempotency token универсальна для протоколов:

Kafka idempotent producer: enable.idempotence=true присваивает Producer ID и sequence number каждому сообщению. Брокер отбрасывает дубликаты в рамках сессии. Для cross-partition атомарности: Kafka транзакции.

Деплой: middleware, а не ручная реализация

Ручная реализация idempotency в каждом эндпоинте порождает несогласованные формулы fingerprint и несовместимые TTL. Middleware-библиотеки делают это один раз:

• express-idempotency (Node.js)
• django-idempotency-key (Python/Django)
• fastapi-idempotency (Python/FastAPI)
• AspNetCore.Idempotency (.NET)
• Stripe idempotent-requests (open-source)

На инфраструктурном уровне: AWS API Gateway со встроенной идемпотентностью с 2023 года (TTL до 10 минут per-stage). Envoy/Istio выставляют retry policy per-route с retry budget по кластеру.