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

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

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

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

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

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

TRAP #1
MISSING AN EVENT

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

JakubPilimon

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)

TRAP #2
VERSIONING OF BEHAVIOR

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

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

TRAP #3
EXTERNAL CALLS

JakubPilimon
TAXES
ChargingSessionFinished
TAX RATES

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

TRAP #4
IGNORING CAP THEOREM

TRAP #5
ANEMIC EVENTS

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

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

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

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

TRAP #6
VERSIONING OF EVENTS

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

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

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

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

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