> [!abstract] An architecture where business events trigger business functionality. It lets you tell the story of your business through its technical implementation. ## Event Driven vs Event Based - **Event-based**: technical events trigger functionality (button clicks, file uploads, S3 object created) - **Event-driven**: business events trigger business functionality (order confirmed, pizza boxed, staff member clocked in) Two businesses in the same domain will have different business events, but similar technical events. ## What is an Event? An **immutable fact** - something that happened in the past that cannot be changed. Simply a notification that something has happened somewhere else. ## Key Concepts - [[Notification Events vs Fat Events]] - **Publish-Subscribe Pattern**: producers → message channel (bus/topic/stream) → consumers - Practice **event-first design** - your event schema is the contract between services ## Benefits - Reduces [[Coupling]] (especially runtime and location coupling) - Creates shared language with business stakeholders - Services are not responsible for consumer constraints (rate limits, etc.) ## Tradeoffs - Requires embracing **eventual consistency** - Paradigm shift from request/response thinking - Need to handle [[Event Versioning]] carefully ## Related Patterns - [[CQRS]] - [[Transactional Outbox Pattern]] - [[Claim Check Pattern]] ## Sources [[x_Sources/Videos/Video - Build An Event Driven System - NDC Oslo 2024|Build An Event Driven System - James Eastham (NDC Oslo 2024)]]