Между сервисами обычно приходится жертвовать сильной консистентностью в пользу eventual consistency, и полагаться на CQRS и event sourcing, чтобы сделать это практичным и корректным.
После изменения реплики сходятся «вскоре» вместо мгновенного схождения. Приемлемо для большинства бизнес-процессов (количество товаров на складе может отставать на секунду), неприемлемо для некоторых (проверка баланса банковского счета).
Разделите write model от одной или нескольких read models.
Command ─▶ Write model ─emits events─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (denormalized, fast)
Чтения масштабируются и изменяют структуру независимо от записей; read model обновляется из событий, поэтому он в конечном итоге консистентен.
Сохраняйте последовательность событий как источник истины, а не только текущее состояние. Текущее состояние — это результат свертывания событий.
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ state: balance = 70
(events are immutable + append-only → full audit + time travel)
| Техника | Преимущества | Издержки |
|---|---|---|
| Eventual consistency | Доступность, масштабируемость | Устаревшие прочитанные данные, конфликты |
| CQRS | Масштабируемость чтений/записей | Два модели, которые нужно синхронизировать |
| Event sourcing | Аудит, переигрывание, история | Эволюция схемы/событий, сложность |
Не применяйте event sourcing везде — это мощный, но тяжелый подход. Используйте его там, где аудит/история действительно важны.
Распределенные системы не могут одновременно иметь сильную консистентность, доступность и отказоустойчивость к разделению, поэтому старший дизайн — это выбор мест, где eventual consistency приемлема.
CQRS и event sourcing дают вам инструменты, чтобы сделать eventual consistency надежным и проверяемым — но каждый добавляет реальную сложность, поэтому применяйте их избирательно, а не по умолчанию.