Event Sourcing & CQRS from the Trenches • Sidney Shek • YOW! 2016

Events should be treated as an API between commands and queries - they are the contract between different parts of the system

Start small with event sourcing:

• Begin with a limited domain scope
• Use simple set events with small payloads
• Split event streams strategically
• Get comfortable with the concepts before expanding

Split streams intelligently:

• Can split by event type or entity type
• Per-user streams provide more flexibility
• Independent events should go on different streams
• Consider contention patterns when designing streams

Query views and event handling:

• Commands and queries should have separate data models
• Query views can be updated lazily on request
• Single event stream should only update one field/table
• Use query synchronizers to maintain consistency

Design considerations:

• Challenge existing requirements - don’t blindly copy constraints
• Enforce business rules on command side, not in data store
• Foreign key constraints add limited value
• Events are immutable but schemas can evolve
• Consider transaction boundaries carefully

Infrastructure benefits:

• Easy to copy data between regions due to immutability
• Can replay events to new schemas without downtime
• Enables multi-active region systems when designed properly
• Provides natural audit trails
• Simplifies testing with production data

Team and organizational aspects:

• Team needs to be willing to challenge traditional approaches
• Start with event sourcing before introducing full CQRS
• Get team comfortable with eventual consistency
• Demonstrate business value through flexibility and scalability