04. Reliability and Consistency¶
Главная · Предыдущий · Следующий · Редакционный стандарт
Раздел описывает инвариант → точку отказа → состояние участников → recovery → независимую сверку. Учебные архитектуры не описывают конкретные компании. Documented behavior, локальный runtime и непроверенная распределённая интеграция имеют разные статусы.
Основные темы¶
- At-most-once, at-least-once и exactly-once
- End-to-end processing guarantees
- Idempotency и deduplication
- Transaction boundaries и atomicity
- Retry, exponential backoff и jitter
- DLQ, poison messages и quarantine
- Backpressure и overload protection
- Circuit Breaker, Bulkhead и Timeouts
- Distributed locks, fencing tokens и leases
- Ordering, sequencing и out-of-order events
- Data Quality и Data Contracts
- Reconciliation и financial correctness
- Disaster Recovery, RPO и RTO
- Observability: metrics, logs и tracing
- Schema evolution и compatibility
- Audit trails, lineage и retention
- GDPR, PCI DSS и PII protection
- Failure injection и chaos engineering
Сравнения и практические сценарии¶
- Восемь сравнений
- Восемь failure scenarios A–H
- Восемь fault-injection labs
- Failure matrix
- Источники и версии
- Отчёт и ограничения (архив рабочего проекта)
Типичные ошибки проектирования¶
Приравнивать delivery к effect; Kafka transaction к PG transaction; Flink checkpoint к durable Redis state; replication к backup; DQ к финансовой сверке; audit log к legal compliance.
Вопросы на собеседовании¶
Как выяснить результат потерянного COMMIT ACK? Через stable operation ID на authoritative state и атомарный повтор, не через создание новой операции. Детали — в сценарии B.
Практические упражнения¶
Для одной цепочки заполнить failure matrix, определить oracle и выполнить fault в подтверждённой boundary. NOT_RUN оставлять явно, не заменять static PASS.
Дополнительные источники¶
Реестр reliability · Processing research. Версии — reference baselines, не рекомендация latest/security support.