Надёжность распределённых систем: карта
Навигатор по надёжности распределённых систем: консенсус, согласованность, атомарность и транзакции, гарантии доставки сообщений и устойчивость под нагрузкой — как это связано и в каком порядке разбираться
Архитектура
Consensus Landscape: тур по алгоритмам консенсуса через симулятор
Флагманский тур по ландшафту консенсуса: осваиваем Raft, Paxos, Zab и EPaxos, воспроизводя перевыборы, сетевые партиции и цену latency в интерактивном симуляторе.
Гарантии доставки и идемпотентность: как получить effectively-once
Вся событийная архитектура держится на одной связке, которую редко проговаривают вслух: at-least-once доставка + идемпотентный консьюмер = effectively-once. Разбираем, почему сквозной exactly-once недостижим в принципе, чем at-least-once отличается от at-most-once, как сделать консьюмер идемпотентным (ключи идемпотентности, dedup-хранилище, естественная идемпотентность, окно дедупа) и где эта связка уже работает в серии — в outbox, saga и проекциях
Досрочное погашение и архитектурные решения: почему ранняя коррекция курса обходится дешевле
Аннуитетный кредит как модель технического долга. Интерактивный калькулятор, реальные ставки ЦБ РФ и архитектурная аналогия: чем раньше вы меняете курс – тем дешевле это стоит
Что кладём в событие: notification vs event-carried state transfer
Самое базовое решение событийной архитектуры — что положить в событие: тонкое уведомление (просто «заказ изменился», ID) или толстое событие с полным состоянием. Первое слабо связывает, но провоцирует «GET-storm» обратно на источник; второе автономно, но раздувает payload, устаревает и тащит связанность по данным. Разбираем два паттерна из таксономии Фаулера, их компромиссы (связанность ↔ автономность ↔ staleness), версионирование нагрузки, приватность в событии и когда что выбирать
Хореография vs оркестрация: кто знает бизнес-процесс
Многошаговый процесс между сервисами координируют двумя способами: хореография — сервисы реагируют на события, единого дирижёра нет, поток эмерджентный; оркестрация — центральный координатор явно ведёт шаги и обрабатывает отказы. Разница не в технологии, а в том, ГДЕ живёт знание о процессе: размазано по сервисам или собрано в одном месте. Разбираем компромиссы, антипаттерны (event-спагетти vs god-оркестратор), когда что и почему реальные системы почти всегда гибрид
Ошибки, паники и исключения: как языки обращаются с отказами
Как Go, Rust, C++ и Java проводят границу между ожидаемым отказом и сломанным инвариантом, и как осознанно выбирать между возвратом ошибки, паникой и исключением
Temporal: durable workflows вместо самодельных очередей
Что такое Temporal, какие задачи он решает, чем отличается от очередей и saga-оркестраторов и когда стоит его внедрять, а когда достаточно простого решения
Saga: распределённые транзакции без двухфазного коммита
Как паттерн Saga решает проблему распределённых транзакций, чем оркестрация отличается от хореографии и когда saga создаёт больше проблем, чем решает
Контракты событий: schema evolution без боли
Событие как публичный контракт: naming, обратная и прямая совместимость, безопасные и ломающие изменения схемы, JSON против Avro/Protobuf, schema registry, consumer-driven contracts и upcasting
В работе
Ближайшие материалы, которые продолжают этот раздел.
Consensus Landscape: как устроены подходы к консенсусу и зачем этот проект
Материал вокруг проекта, карты подходов к консенсусу и того, как по ней читать distributed systems без каши в голове.
System Design без культа идеальных схем
Как подходить к системному дизайну через ограничения и trade-offs, а не через коллекцию красивых диаграмм.