Девять изменений схемы через Avro, Protobuf и JSON Schema в двух направлениях, и три исхода вместо двух: прочиталось, отказ и — самый дорогой — прочиталось неверно. Одно изменение дало три разных операционных ответа: два декодера и реестр схем
Сколько на самом деле стоит бинарный формат: вес записи, вес схемы и что остаётся от разницы под сжатием. Плюс проверка того, что нужно иметь на руках, чтобы данные вообще прочитались — и почему у контрольного плеча этот вес равен нулю
Концепция саги проста, а прод — нет: компенсация это не rollback, а обратное семантическое действие, и её порядок, идемпотентность и «а если компенсация упала» решают, работает система или разваливается. Плюс изоляция: сага даёт ACD, не ACID — грязные чтения и потерянные обновления реальны, и с ними борются семантическими локами и контрмерами. Разбираем классификацию шагов (compensatable/pivot/retriable), персистентность саги, tooling (Temporal/Camunda/Axon) и тестирование с инъекцией отказов
Разделить чтение и запись — идея на слайде. На проде всё в проекциях: как строить read-модели, как жить с их отставанием (read-your-writes ломается), как пересобирать проекцию без даунтайма (blue-green, чекпоинты, идемпотентное применение) и когда CQRS оправдан без Event Sourcing, а когда тащит его за собой. Разбираем sync vs async проекции, несколько read-моделей на запрос, tooling (Axon/EventStoreDB/Marten) и типовую ошибку — CQRS поверх обычного CRUD
Финальная карта серии: когда хватит CRUD с audit log, когда нужен Outbox, CQRS, Event Sourcing, Saga или Temporal — по осям границ, истории, длительности процесса и требований к согласованности
Вся событийная архитектура держится на одной связке, которую редко проговаривают вслух: at-least-once доставка + идемпотентный консьюмер = effectively-once. Разбираем, почему сквозной exactly-once недостижим в принципе, чем at-least-once отличается от at-most-once, как сделать консьюмер идемпотентным (ключи идемпотентности, dedup-хранилище, естественная идемпотентность, окно дедупа) и где эта связка уже работает в серии — в outbox, saga и проекциях
Ментальная модель NATS через знакомые понятия: subjects вместо exchanges и topics, встроенный request/reply, queue groups и почему Core NATS — это at-most-once транспорт без хранения
Самое базовое решение событийной архитектуры — что положить в событие: тонкое уведомление (просто «заказ изменился», ID) или толстое событие с полным состоянием. Первое слабо связывает, но провоцирует «GET-storm» обратно на источник; второе автономно, но раздувает payload, устаревает и тащит связанность по данным. Разбираем два паттерна из таксономии Фаулера, их компромиссы (связанность ↔ автономность ↔ staleness), версионирование нагрузки, приватность в событии и когда что выбирать
Многошаговый процесс между сервисами координируют двумя способами: хореография — сервисы реагируют на события, единого дирижёра нет, поток эмерджентный; оркестрация — центральный координатор явно ведёт шаги и обрабатывает отказы. Разница не в технологии, а в том, ГДЕ живёт знание о процессе: размазано по сервисам или собрано в одном месте. Разбираем компромиссы, антипаттерны (event-спагетти vs god-оркестратор), когда что и почему реальные системы почти всегда гибрид
Событие как публичный контракт: naming, обратная и прямая совместимость, безопасные и ломающие изменения схемы, JSON против Avro/Protobuf, schema registry, consumer-driven contracts и upcasting
