Концепцию Event Sourcing легко полюбить и трудно эксплуатировать: где хранить события (EventStoreDB vs Kafka vs Postgres), как строить и перестраивать проекции (read models), зачем снапшоты и как их делать, как реплеить историю, что такое upcasting при эволюции событий, оптимистичный конкаренси-контроль через expected version — и как жить с append-only, когда приходит GDPR-запрос на удаление
Финальная карта серии: когда хватит CRUD с audit log, когда нужен Outbox, CQRS, Event Sourcing, Saga или Temporal — по осям границ, истории, длительности процесса и требований к согласованности
Навигатор по надёжности распределённых систем: консенсус, согласованность, атомарность и транзакции, гарантии доставки сообщений и устойчивость под нагрузкой — как это связано и в каком порядке разбираться
Флагманский тур по ландшафту консенсуса: осваиваем Raft, Paxos, Zab и EPaxos, воспроизводя перевыборы, сетевые партиции и цену latency в интерактивном симуляторе.
Вся событийная архитектура держится на одной связке, которую редко проговаривают вслух: at-least-once доставка + идемпотентный консьюмер = effectively-once. Разбираем, почему сквозной exactly-once недостижим в принципе, чем at-least-once отличается от at-most-once, как сделать консьюмер идемпотентным (ключи идемпотентности, dedup-хранилище, естественная идемпотентность, окно дедупа) и где эта связка уже работает в серии — в outbox, saga и проекциях
Аннуитетный кредит как модель технического долга. Интерактивный калькулятор, реальные ставки ЦБ РФ и архитектурная аналогия: чем раньше вы меняете курс – тем дешевле это стоит
Самое базовое решение событийной архитектуры — что положить в событие: тонкое уведомление (просто «заказ изменился», ID) или толстое событие с полным состоянием. Первое слабо связывает, но провоцирует «GET-storm» обратно на источник; второе автономно, но раздувает payload, устаревает и тащит связанность по данным. Разбираем два паттерна из таксономии Фаулера, их компромиссы (связанность ↔ автономность ↔ staleness), версионирование нагрузки, приватность в событии и когда что выбирать
Многошаговый процесс между сервисами координируют двумя способами: хореография — сервисы реагируют на события, единого дирижёра нет, поток эмерджентный; оркестрация — центральный координатор явно ведёт шаги и обрабатывает отказы. Разница не в технологии, а в том, ГДЕ живёт знание о процессе: размазано по сервисам или собрано в одном месте. Разбираем компромиссы, антипаттерны (event-спагетти vs god-оркестратор), когда что и почему реальные системы почти всегда гибрид
Как Go, Rust, C++ и Java проводят границу между ожидаемым отказом и сломанным инвариантом, и как осознанно выбирать между возвратом ошибки, паникой и исключением
Что такое Temporal, какие задачи он решает, чем отличается от очередей и saga-оркестраторов и когда стоит его внедрять, а когда достаточно простого решения
