This document discusses common traps that can be encountered when implementing an event-driven architecture and provides solutions to avoid them. It covers traps such as missing domain events, versioning of behaviors and data over time, issues with external calls and consistency, ignoring the CAP theorem, having anemic domain events, and versioning of event schemas. The document provides explanations for why each trap occurs and recommends approaches like event storming, embedding results in domain events, weak schemas, and schema translation to help address the issues.

1. JakubPilimon
EVENT-DRIVEN ARCHITECTURE
TRAPS
… AND HOW TO AVOID THEM

2. JakubPilimon
DISCLAIMERS
• Traps based on private experiences
• Solutions worked in my contexts
• Haven’t pushed anything to production since … 6 months
• … But this is based on previous experiences
• Completely new content, so things might not work
• … Please don’t throw tomatoes

3. JakubPilimon
WHOAMI
SPRING DEVELOPER ADVOCATE
AND PROGRAMMER
Loves to tackle complex enterprises with:
• Domain-Driven Design,
• Event Storming,
• Test-Driven Development,
• Spring
Being a microservice freak, architecture is his main area of interest too.
DZone MVB awarded blog: pillopl.github.io
Co-founder of #dddbyexamples initiative: github.com/ddd-by-examples

4. JakubPilimon
PATTERN THAT PROMOTES DETECTION
AND REACTION TO STATE CHANGES
REPRESENTED BY DOMAIN EVENTS
ME
EVENT-DRIVEN TO ME

5. JakubPilimon
EVENT-DRIVEN TO ME
• EDA != “I have microservices”
• EDA != “I have a message broker”
• Events might be transported for instance via HTTP
• Events can live only in application memory
• … Events might not be even visible in the code
• … but domain event is there in the business process
• Event Sourcing counts too

6. JakubPilimon
EVENT-DRIVEN TO ME
EVENT 1
EVENT 2
EVENT 3
JMS/AMQP
HTTP
IN MEMORY
DB #1 DB #1 or not
DB #2

7. TRAP #1
MISSING AN EVENT

8. JakubPilimon
BACKEND2. Start transaction
1. Customer plugged in
4. Stop transaction
3. Customer finished charging
BACKEND
5. Customer unplugged

9. JakubPilimon

10. JakubPilimon
TRAP #1: MISSING AN EVENT
REASONS:
▸ Treating boundary of software as equals to boundary of business process
▸ Not spotting that our piece of software is not source of truth
▸ There is semantics of the protocol and there is implementation
SOLUTIONS:
▸ Event Storming can help you find EXTERNAL events and boundaries of your software
▸ Think about assumptions you make about consistency and don’t try to be consistent
no matter what (sometimes it is impossible)
▸ Attach to semantics, not to implementation (focus on an intention of any
communication)

11. TRAP #2
VERSIONING OF BEHAVIOR

12. JakubPilimon
BACKEND1. Stop session
BACKEND TAXES
2. ChargingSessionFinished
TAXES
3. Calculate and insert tax
EVENT 1
EVENT 2
EVENT 3

13. JakubPilimon
TRAP #2: VERSIONING OF BEHAVIORS
REASONS:
▸ Hard-coded values are not temporal
▸ Occurred vs Arrived mismatch!
SOLUTIONS:
▸ Calculation logic in projection should be done at time of event creation
and the result should be inside the event
▸ Same with external calls

14. TRAP #3
EXTERNAL CALLS

15. JakubPilimon
TAXES
ChargingSessionFinished
TAX RATES

16. JakubPilimon
TRAP #3: EXTERNAL CALLS
REASONS:
▸ Thinking that external systems are always temporal
▸ Relying on single point of truth
SOLUTIONS:
▸ External calls should be done at time of event creation and the result should be
inside the event
▸ Listening to another upstream of events and join both streams by building local
read model

17. TRAP #4
IGNORING CAP THEOREM

18. TRAP #5
ANEMIC EVENTS

19. JakubPilimon
TRANSACTION LOG
MYSQL
session.finish();
T1 T2 T3 T4 T…
1
2
3
4
5
6
7
8
9
10
3
7
9
1
4
5
6
“charging_sessions”
Stream of events

20. JakubPilimon
TRAP #5: ANEMIC-EVENTS
REASONS:
▸ Focusing on data instead of behaviors
SOLUTIONS:
▸ Domain events (with behavior)
▸ Thinking about business intent of any change, not only
about the representation of that change

21. JakubPilimon
TRANSACTION
eventPublisher.publish(…);
proxy.commit(…);
chargingSessionRepository
.findById(…)
session.finish(…);

22. JakubPilimon
TRAP #4: IGNORING CAP THEOREM
REASONS:
▸ Ignoring the fact that every now and then things will not work
▸ Trying to be consistent NOW!
▸ Experience with 2PC
SOLUTIONS:
▸ At-least once (and deduplicating) or at-most once
▸ Event sourcing
▸ Listen to yourself
▸ Log tailing

23. TRAP #6
VERSIONING OF EVENTS

24. JakubPilimon
I WILL JUST FIND IT AND
UPDATE IT. WHAT CAN
POSSIBLY GO WRONG?

25. JakubPilimon
1
2
3
“sessions”
BACKEND
4
4’
ChargingSessionFinished
Charging session has finished
ChargingSessionFinishedV2
CONSUMER1 CONSUMER2
4 4’

26. JakubPilimon
1
2
3
1’
2’
3’
“sessions” “sessions-v2”
TRANSLAT
OR

27. JakubPilimon
TRAP #6: VERSIONING OF EVENTS
REASONS:
▸ Using strong schema
▸ Canonical shared model of events - coupling
SOLUTIONS:
▸ Double-write
▸ Weak schema
▸ Copy and replace
▸ Schema server

28. JakubPilimon
QUESTIONS?
https://github.com/pilloPl/edatraps
https://github.com/ddd-by-examples