00 Mental model: how to reason about failure modesМентальная модель: как рассуждать о режимах сбоев
The single thread that runs through every distributed-systems answer. Lead with this framing.
Единая нить, проходящая через каждый ответ о распределённых системах. Начинай с этого фрейминга.
Distributed systems is the study of what happens when independent failure meets unbounded message delay. A senior answer always names: (1) what can fail, (2) how you detect it, (3) how the system behaves during the failure, (4) how it recovers, and (5) what guarantee survives the whole thing.
Распределённые системы — это изучение того, что происходит, когда независимый сбой встречается с неограниченной задержкой сообщений. Ответ senior-уровня всегда называет: (1) что может упасть, (2) как ты это обнаруживаешь, (3) как система ведёт себя во время сбоя, (4) как она восстанавливается, и (5) какая гарантия переживает всё это.
The reasoning checklist (say it out loud)
Чек-лист рассуждений (произноси вслух)
- Enumerate failure domains: node crash, slow node (gray failure), disk full, network partition, clock skew, dependency down, poison message, traffic spike.
- Pick the model: crash-stop vs crash-recovery vs Byzantine; synchronous vs partially-synchronous network (real world = partially synchronous).
- Detection: timeouts and heartbeats are suspicion, not truth. You can never distinguish "dead" from "slow" — this is the FLP impossibility in practice.
- Blast radius: does one failure cascade? Bulkheads, timeouts, circuit breakers, backpressure.
- Recovery + guarantee: idempotency, retries with jitter, replay from durable log, checkpoint/offset rewind.
- Перечисли домены сбоев: падение ноды, медленная нода (gray failure), диск полон, разделение сети, перекос часов, зависимость упала, poison-сообщение, всплеск трафика.
- Выбери модель: crash-stop vs crash-recovery vs Byzantine; синхронная vs частично синхронная сеть (реальный мир = частично синхронная).
- Обнаружение: таймауты и heartbeat — это подозрение, не истина. Ты никогда не различишь «мёртвый» от «медленный» — это FLP impossibility на практике.
- Радиус поражения: один сбой каскадирует? Bulkheads, таймауты, circuit breakers, backpressure.
- Восстановление + гарантия: идемпотентность, ретраи с jitter, переигрывание из надёжного лога, откат checkpoint/offset.
Senior framing
"I assume partial failure is the steady state, not an exception. I design every write to be retry-safe (idempotent), every consumer to be replay-safe (dedup + checkpoint), and I make timeouts/backpressure explicit so a slow dependency degrades instead of collapsing."
Фрейминг senior-уровня
«Я исхожу из того, что частичный сбой — это норма, а не исключение. Я делаю каждую запись безопасной для ретраев (идемпотентной), каждого консьюмера безопасным для переигрывания (дедуп + checkpoint), и делаю таймауты/backpressure явными, чтобы медленная зависимость деградировала, а не рушилась.»
Interviewer will probe
"A node stops responding. Is it dead or slow, and does it matter?" — Correct answer: you cannot tell them apart, so the protocol must be correct under either. Fencing tokens / leases stop a "slow-then-revived" leader from doing damage.
О чём спросит интервьюер
«Нода перестала отвечать. Она мёртвая или медленная, и важно ли это?» — Правильный ответ: ты не можешь их различить, поэтому протокол должен быть корректен при любом. Fencing tokens / leases останавливают «медленно-потом-ожившего» лидера от нанесения вреда.
01 CAP theorem & PACELCТеорема CAP и PACELC
The most-asked opener. Be precise: CAP is about behavior during a partition, not a permanent property.
Самый частый вопрос на открытие. Будь точен: CAP — про поведение во время разделения, а не постоянное свойство.
CAP, stated correctly
CAP, сформулированная правильно
During a network Partition, a distributed store can preserve at most one of Consistency (linearizable reads) or Availability (every non-failing node answers). When there is no partition, you get both — CAP says nothing about the happy path.
Во время разделения сети (Partition) распределённое хранилище может сохранить максимум одно из Consistency (линеаризуемое чтение) или Availability (каждая не-упавшая нода отвечает). Когда разделения нет, получаешь оба — CAP ничего не говорит про happy path.
- CP — refuse/block on the minority side to stay consistent. (ZooKeeper, etcd, HBase, Spanner-as-CP.)
- AP — keep answering, reconcile later, tolerate stale/conflicting reads. (Dynamo, Cassandra default, Riak.)
- "CA" is not a real operating point for a networked system — partitions will happen, so you only choose C-vs-A for the partition.
- CP — отказывать/блокироваться на стороне меньшинства, чтобы сохранить консистентность. (ZooKeeper, etcd, HBase, Spanner-как-CP.)
- AP — продолжать отвечать, согласовывать потом, терпеть устаревшие/конфликтующие чтения. (Dynamo, Cassandra по умолчанию, Riak.)
- «CA» — не реальная точка работы для сетевой системы — разделения будут происходить, поэтому выбираешь только C-против-A для разделения.
Common gotcha
"Consistency" in CAP = linearizability, a very strong model. It is NOT the "C" in ACID. Many "AP" systems still give per-key strong-ish guarantees; many "CP" systems are tunable. Avoid binary labels; talk about knobs.
Частая ошибка
«Consistency» в CAP = линеаризуемость, очень сильная модель. Это НЕ «C» в ACID. Многие «AP»-системы всё равно дают сильноватые гарантии на ключ; многие «CP»-системы настраиваемы. Избегай бинарных ярлыков; говори о ручках настройки.
PACELC — the more useful version
PACELC — более полезная версия
CAP ignores the cost you pay when the system is healthy. PACELC fixes that:
CAP игнорирует цену, которую ты платишь, когда система здорова. PACELC это исправляет:
if (Partition): trade A vs C
else (Else): trade L vs C (Latency vs Consistency)
if (Partition): trade A vs C
else (Else): trade L vs C (Задержка vs Консистентность)
| System | On partition (PA/PC) | Else, normal (EL/EC) | Class |
|---|---|---|---|
| Dynamo / Cassandra | PA (stay up) | EL (fast, eventual) | PA/EL |
| Spanner | PC (consistent) | EC (TrueTime waits) | PC/EC |
| etcd / ZooKeeper | PC | EC | PC/EC |
| MongoDB (default) | PC | EC (primary reads) | PC/EC |
| Cassandra (tuned QUORUM) | PC-ish | EC-ish | tunable |
| Система | При разделении (PA/PC) | Иначе, норма (EL/EC) | Класс |
|---|---|---|---|
| Dynamo / Cassandra | PA (остаться в сети) | EL (быстро, eventual) | PA/EL |
| Spanner | PC (консистентно) | EC (TrueTime ждёт) | PC/EC |
| etcd / ZooKeeper | PC | EC | PC/EC |
| MongoDB (default) | PC | EC (чтение с primary) | PC/EC |
| Cassandra (tuned QUORUM) | PC-ish | EC-ish | настраиваема |
Why PACELC matters for DE
99% of the time there is no partition, so the EL vs EC trade is what you actually live with daily: synchronous quorum reads cost p99 latency; eventual reads are fast but may be stale. For an analytics serving layer you usually pick EL and design downstream to tolerate staleness.
Почему PACELC важен для DE
99% времени разделения нет, поэтому компромисс EL vs EC — это то, с чем ты живёшь каждый день: синхронное чтение с кворума стоит p99 задержки; eventual чтения быстрые, но могут быть устаревшими. Для аналитического serving-слоя обычно выбираешь EL и проектируешь downstream, чтобы терпеть staleness.
Interviewer will probe
"Spanner claims CA / 'beats CAP'." — It does not. It is CP: under a true partition the minority becomes unavailable. Its trick is making partitions rare (Google's private network) and using TrueTime (bounded clock uncertainty) to keep latency acceptable while staying externally consistent.
О чём спросит интервьюер
«Spanner заявляет CA / "побеждает CAP".» — Нет. Это CP: при настоящем разделении меньшинство становится недоступным. Его трюк — делать разделения редкими (частная сеть Google) и использовать TrueTime (ограниченная неопределённость часов), чтобы держать задержку приемлемой, оставаясь externally consistent.
02 Consistency modelsМодели консистентности
A spectrum from "always correct, slow" to "fast, surprising". Know where each sits and the client guarantees.
Спектр от «всегда корректно, медленно» до «быстро, сюрпризы». Знай, где находится каждая и какие гарантии клиенту.
STRONGER / SLOWER WEAKER / FASTER
Linearizable ─ Sequential ─ Causal ─ Read-your-writes ─ Eventual
(single, (global (cause (session (converges
real-time order, no before sees own eventually,
order) real-time) effect) writes) no order)
СИЛЬНЕЕ / МЕДЛЕННЕЕ СЛАБЕЕ / БЫСТРЕЕ
Linearizable ─ Sequential ─ Causal ─ Read-your-writes ─ Eventual
(единый, (глобальный (причина (сессия (сходится
real-time порядок, раньше видит свои в итоге,
порядок) не real-time) эффекта) записи) нет порядка)
| Model | Guarantee | Cost | Use it for |
|---|---|---|---|
| Linearizable / Strong | Every read returns the latest committed write as of a real-time point; behaves like one copy. | Quorum / consensus round-trips; latency + availability hit. | Locks, leader election, counters, balances, config. |
| Sequential | All nodes see ops in same order, but not necessarily real-time order. | Cheaper than linearizable. | Replicated state machines. |
| Causal | Operations that are causally related are seen in order by everyone; concurrent ops can differ. | Track causality (version vectors); cheap, available. | Collaborative apps, comments/replies, messaging. |
| Read-your-writes (session) | A client always sees its own prior writes. | Sticky routing or version tokens. | "I posted but don't see it" UX bugs. |
| Monotonic reads | Time never goes backwards for a client. | Pin to a replica / hold a token. | Avoid "now you see it, now you don't". |
| Eventual | If writes stop, all replicas converge. | Cheapest, most available. | Caches, analytics, feeds, metrics. |
| Модель | Гарантия | Цена | Применяй для |
|---|---|---|---|
| Linearizable / Strong | Каждое чтение возвращает последнюю закоммиченную запись на момент real-time; ведёт себя как одна копия. | Кворум / консенсус round-trips; удар по задержке + доступности. | Блокировки, выбор лидера, счётчики, балансы, конфиги. |
| Sequential | Все ноды видят операции в одинаковом порядке, но не обязательно real-time. | Дешевле linearizable. | Реплицированные state machines. |
| Causal | Причинно связанные операции видны всеми в порядке; конкурентные операции могут отличаться. | Отслеживание причинности (version vectors); дёшево, доступно. | Коллаборативные приложения, комментарии/ответы, мессенджинг. |
| Read-your-writes (сессия) | Клиент всегда видит свои предыдущие записи. | Sticky routing или version tokens. | Баги UX «я запостил, но не вижу». |
| Monotonic reads | Время никогда не идёт назад для клиента. | Привязка к реплике / держать токен. | Избегать «то вижу, то не вижу». |
| Eventual | Если записи остановятся, все реплики сойдутся. | Дешевле всего, максимально доступно. | Кеши, аналитика, ленты, метрики. |
Gotcha — "eventual" is underspecified
Eventual consistency gives no session guarantees by default. A user can write, then read an older replica and not see it. Read-your-writes, monotonic reads, and causal are the practical "session guarantees" that make eventual systems usable for humans.
Ошибка — «eventual» недоспецифицирована
Eventual consistency не даёт гарантий сессии по умолчанию. Пользователь может записать, потом прочитать старую реплику и не увидеть. Read-your-writes, monotonic reads и causal — это практические «гарантии сессии», делающие eventual-системы юзабельными для людей.
Interviewer will probe
"A user updates their profile photo and on refresh sees the old one — what's wrong and how do you fix it?" → Eventual store + read hit a lagging replica. Fix: read-your-writes via sticky session, write-through cache, or a version token that forces reading a replica that is ≥ the write.
О чём спросит интервьюер
«Пользователь обновил фото профиля и при обновлении видит старое — что не так и как чинить?» → Eventual хранилище + чтение попало в отстающую реплику. Лечение: read-your-writes через sticky session, write-through cache или version token, который заставляет прочитать реплику ≥ записи.