Theory
CAP теорема
Консистентность всегда выбирается через компромисс с доступностью и latency.
Паттерны консистентности и идемпотентность позволяют системе безопасно переживать retries, redelivery и частичные сбои. Ключевой принцип: невозможно полагаться только на "идеальную доставку" - система должна быть корректной даже при повторных и неупорядоченных событиях.
Related
Jepsen consistency models
Эмпирическая проверка моделей консистентности и реального поведения распределённых БД под сбоями.
Модели консистентности
Strong consistency
Финансовые операции, критичные инварианты, операции с высокой ценой ошибки.
Выше latency/стоимость и ниже доступность при partition-сценариях.
Read-your-writes / session consistency
Пользовательские кабинеты и UX, где важно видеть собственные изменения сразу.
Нужно учитывать session routing/sticky reads и кэш-валидацию.
Eventual consistency
Каталоги, рекомендации, аналитические витрины, асинхронные интеграции.
Появляется временное рассогласование, требуется UI/бизнес-политика обработки лагов.
Паттерны идемпотентности
Активный паттерн
Idempotency Key для sync API
POST/command операции: платежи, создание заказа, выдача инвойса, запуск workflow.
Как реализовать
- Клиент передает `Idempotency-Key`, сервер сохраняет key + fingerprint запроса + итог ответа.
- При повторе с тем же key и тем же payload возвращается исходный результат, а не новая операция.
- TTL ключа выбирается по бизнес-риску (часто 24-72 часа для финансовых сценариев).
Риск: Если reused key приходит с другим payload, возвращайте ошибку конфликта, иначе получите скрытые дубли.
Практические guardrails
- Идемпотентность защищает от duplicate delivery, но не заменяет контроль конкурентности и инвариантов.
- Для критичных команд храните не только факт обработки, но и canonical response/reason code для replay.
- Мониторьте hit-rate повторов, долю dedupe reject и время обработки конфликтов ключей.
Validation
Testing Distributed Systems
Идемпотентность должна подтверждаться тестами duplicate/out-of-order сценариев.
Примеры сценариев использования
Платежный API
Повтор запроса после timeout без идемпотентного контракта часто приводит к двойному списанию.
Failure path
Client
timeout + retry
Payment API
no idempotency key
DB
duplicate charge
User
double debit
Resilient path
Client
Idempotency-Key
API
dedupe + unique constraint
Ledger
single transaction
API
status replay
Что происходит
- Ключ идемпотентности связывает повторы одного намерения клиента в одну бизнес-операцию.
- Даже при повторной доставке сервер возвращает тот же результат вместо новой транзакции.
- Unique constraint и status endpoint закрывают race-сценарии между ретраями.
Риск: Срок жизни ключа и его scope должны совпадать с бизнес-временем операции.
Сценарий должен быть корректен при retries, redelivery и out-of-order delivery.
Практический чеклист
Для каждого critical command определено, как система обрабатывает duplicate requests.
У событий есть уникальный identity и consumer deduplication strategy.
Модель консистентности выбрана осознанно и отражена в API-контрактах/документации.
Есть reconciliation-процессы для обнаружения и исправления рассогласований.
Команда тестирует retries, redelivery и out-of-order delivery в integration tests.
Частый anti-pattern: считать once-only delivery гарантией платформы и не делать операцию идемпотентной.
Связанные главы
CAP теорема
Почему невозможно одновременно максимизировать C, A и P при сетевых разделениях.
PACELC теорема
Как компромисс latency/consistency проявляется даже без аварий.
Event-Driven Architecture
Где идемпотентность и консистентность особенно критичны при event flows.
Паттерны отказоустойчивости
Retry требует идемпотентного контракта, иначе создает бизнес-дубли.
Testing Distributed Systems
Как тестировать duplicate/out-of-order/partial-failure сценарии.