So You Want to Build An Event Driven System? - James Eastham - NDC Oslo 2024

Event-driven architecture (EDA) is fundamentally a communication pattern between services, using business events to drive functionality

Events are immutable facts that have happened in the past and cannot be changed. There are two main types:

• Notification events (thin events) - lightweight packets with minimal data
• State transfer events (fat events) - carry more complete state information

Schema design and evolution is critical:

• Event schema is the highest form of coupling in EDA
• Use versioning and deprecation dates for breaking changes
• Be conservative in what you send, liberal in what you accept
• Consider using standards like CloudEvents specification

Start small when adopting EDA:

• Begin with one small integration point
• Don’t try to make entire system event-driven overnight
• Pick services that aren’t mission-critical for initial implementation

Key patterns to consider:

• Transactional outbox pattern for reliable event publishing
• CQRS (Command Query Responsibility Segregation) for separating reads/writes
• Claim check pattern for handling large payloads
• Async commands for request/response scenarios

Handle asynchronous challenges:

• Implement proper error handling and retry logic
• Consider rate limiting for consumers
• Plan for eventual consistency
• Maintain observability through distributed tracing

Focus on business language and events:

• Use event storming to identify key business events
• Model events using business terminology
• Events should tell the story of your business

Consider coupling carefully:

• Some coupling is necessary and acceptable
• Aim for low coupling and high cohesion
• Services should be unaware of downstream consumers
• Maintain independence between services