> [!abstract] Two approaches to event payload design in [[Event Driven Architecture]]: thin events with just IDs, or fat events carrying full state. ## Notification Events (Thin Events) - Lightweight, only contain identifiers (e.g., order ID) - Consumers must **callback** to get more details - Risk: callback storms as more subscribers are added - Less semantic [[Coupling]] ## Fat Events (Event-Carried State Transfer) - Carry the state needed by consumers - No callbacks required - More semantic coupling - changes to schema affect all consumers - Higher risk of breaking unknown downstream systems ## Postel's Law > Be conservative in what you send, be liberal in what you accept. Less data in events = less semantic coupling. But too thin requires callbacks. ## Middle Ground: Publishing Identifiers Include multiple IDs (order ID, delivery ID, customer ID) rather than full data. Each microservice owns its own data - pass references, not copies. ## Claim Check Pattern Offload additional data to a separate location (cache, API, S3). Events contain an identifier to retrieve data if needed. Prevents overloading core services with callbacks. ## Sources [[x_Sources/Videos/Video - Build An Event Driven System - NDC Oslo 2024|Build An Event Driven System - James Eastham (NDC Oslo 2024)]]