Корректность распределенной системы ломается не только на явном отказе, но и на повторах, запаздывании данных и частично завершенных операциях.
Глава связывает consistency models, read-your-writes, idempotency keys, consumer deduplication, transactional outbox и saga compensation в одну рамку проектирования, где главное - заранее понять, какие инварианты можно ослабить, а какие нельзя терять ни при каких retry и replay.
Для system design interview это очень сильный материал, потому что он позволяет говорить о correctness через реальные safeguards, а не через маркетинговое обещание exactly-once, которое ничего не объясняет про поведение системы при сбое.
Практическая польза главы
Уровень консистентности
Фиксируйте consistency model по use case: strong, bounded staleness или eventual с компенсационными механизмами.
Идемпотентные контракты
Проектируйте API и consumer-обработчики с idempotency keys, dedupe store и контролем повторов.
Сбойные сценарии
Разбирайте race conditions, duplicate delivery и partial commits заранее через explicit failure timeline.
Interview precision
Показывайте, как обеспечите корректность в distributed системе, когда exactly-once недостижим на практике.
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 гарантией платформы и не делать операцию идемпотентной.
References
Связанные главы
- CAP теорема - Почему невозможно одновременно максимизировать C, A и P при сетевых разделениях.
- PACELC теорема - Как компромисс latency/consistency проявляется даже без аварий.
- Event-Driven Architecture - Где идемпотентность и консистентность особенно критичны при event flows.
- Паттерны отказоустойчивости - Retry требует идемпотентного контракта, иначе создает бизнес-дубли.
- Testing Distributed Systems - Как тестировать duplicate/out-of-order/partial-failure сценарии.