Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Event-Driven Architecture Traps

435 views

Published on

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.

Presenter : Jakub Pilimon, Pivotal

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Event-Driven Architecture Traps

  1. 1. JakubPilimon EVENT-DRIVEN ARCHITECTURE TRAPS … AND HOW TO AVOID THEM
  2. 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. 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. 4. JakubPilimon PATTERN THAT PROMOTES DETECTION AND REACTION TO STATE CHANGES REPRESENTED BY DOMAIN EVENTS ME EVENT-DRIVEN TO ME
  5. 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. 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. 7. TRAP #1 MISSING AN EVENT
  8. 8. JakubPilimon BACKEND2. Start transaction 1. Customer plugged in 4. Stop transaction 3. Customer finished charging BACKEND 5. Customer unplugged
  9. 9. JakubPilimon
  10. 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. 11. TRAP #2 VERSIONING OF BEHAVIOR
  12. 12. JakubPilimon BACKEND1. Stop session BACKEND TAXES 2. ChargingSessionFinished TAXES 3. Calculate and insert tax EVENT 1 EVENT 2 EVENT 3
  13. 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. 14. TRAP #3 EXTERNAL CALLS
  15. 15. JakubPilimon TAXES ChargingSessionFinished TAX RATES
  16. 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. 17. TRAP #4 IGNORING CAP THEOREM
  18. 18. TRAP #5 ANEMIC EVENTS
  19. 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. 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. 21. JakubPilimon TRANSACTION eventPublisher.publish(…); proxy.commit(…); chargingSessionRepository .findById(…) session.finish(…);
  22. 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. 23. TRAP #6 VERSIONING OF EVENTS
  24. 24. JakubPilimon I WILL JUST FIND IT AND UPDATE IT. WHAT CAN POSSIBLY GO WRONG?
  25. 25. JakubPilimon 1 2 3 “sessions” BACKEND 4 4’ ChargingSessionFinished Charging session has finished ChargingSessionFinishedV2 CONSUMER1 CONSUMER2 4 4’
  26. 26. JakubPilimon 1 2 3 1’ 2’ 3’ “sessions” “sessions-v2” TRANSLAT OR
  27. 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. 28. JakubPilimon QUESTIONS? https://github.com/pilloPl/edatraps https://github.com/ddd-by-examples

×