Что кладём в событие: notification vs event-carried state transfer
Самое базовое решение событийной архитектуры — что положить в событие: тонкое уведомление (просто «заказ изменился», ID) или толстое событие с полным состоянием. Первое слабо связывает, но провоцирует «GET-storm» обратно на источник; второе автономно, но раздувает payload, устаревает и тащит связанность по данным. Разбираем два паттерна из таксономии Фаулера, их компромиссы (связанность ↔ автономность ↔ staleness), версионирование нагрузки, приватность в событии и когда что выбирать
