Как надёжно публиковать события при изменении данных без распределённой транзакции: outbox, relay/poller, inbox и дедупликация, idempotency key, ordering, poison messages и почему exactly-once — это иллюзия
Что такое CQRS, зачем разделять модели чтения и записи, как это связано с event sourcing и где этот паттерн создаёт больше проблем, чем решает
Что такое event sourcing, какие задачи он решает лучше классического CRUD, где усложняет без пользы и на что смотреть перед внедрением
Какие виды архитектуры бывают в IT, чем отличаются роли архитекторов, и почему архитектурные решения на практике принимают не только люди с «архитектор» в должности
Карта понятий событийной архитектуры: чем команда отличается от события, domain event от integration event, где брокер, где event store, где workflow engine — и как читать остальную серию
Когда конфигурация через env и файлы перестаёт работать, какие задачи решают etcd, Consul и Vault, чем они отличаются и как не усложнить систему раньше времени
Финальная статья архитектурно-аналитической серии: один сценарий лунной базы, пройденный целиком — от problem statement и требований через доменную модель, C4, взаимодействия и согласованность до эксплуатации, чтобы увидеть, как все решения складываются в одну систему
Статья архитектурно-аналитической серии на примере лунной базы: почему эксплуатация — не этап после архитектуры, а её часть, и как наблюдаемость, деградация и восстановление должны проектироваться вместе с системой
Статья архитектурно-аналитической серии на примере лунной базы: как выбирать уровень согласованности данных под реальные сценарии — строгая, eventual или пакетная — и почему «согласованность везде» ломает систему так же, как её отсутствие
Статья архитектурно-аналитической серии на примере лунной базы: как аналитика и архитектура по-разному смотрят на синхронные и асинхронные взаимодействия, REST, события, команды и очереди — и где простая на схеме интеграция оказывается дорогой
Ближайшие материалы, которые продолжают этот раздел.
Материал вокруг проекта, карты подходов к консенсусу и того, как по ней читать distributed systems без каши в голове.
Как подходить к системному дизайну через ограничения и trade-offs, а не через коллекцию красивых диаграмм.
