Event-Driven Architecture Traps

Event-driven architectures (EDA) have become more popular by the day. Organizations see a great value in them, and developers love how EDA help to grow, scale, and mirror what really happens in the business domain. However, most developers are not familiar with this kind of architecture, which can lead to common pitfalls that we’ll examine in this webinar. We’ll also cover a broad set of buzzwords like: exactly-once delivery, Kafka Streams, CQRS, and Spring Cloud Stream. There will be live coding, which will require basic knowledge about distributed systems and Spring Cloud.

Transcript

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 BACKEND 2. 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 BACKEND 1. 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