Talk held at O'Reilly Software Architecture Conference London together with @martinschimak on 16th of October 2017. It is about how to tackle complex event flows in distributed systems (which could be e.g. event-driven microservices). Code from live hacking example is here: https://github.com/flowing/flowing-retail

1. Complex event flows in
distributed systems
O‘Reilly Software Architecture Conference
16th of October 2017
mail@bernd-ruecker.com
martin.schimak@plexiti.com
With thoughts from http://flowing.io
@berndruecker | @martinschimak

2. Bernd Rücker
Consultant & Dev. Advocate
10+ years workflow
Co-founder Camunda
http://bernd-ruecker.com/
Martin Schimak
Consultant & Trainer
15+ years domain (de-)coding
DDDesign, TDD/BDD, EDA
http://plexiti.com/
http://flowing.io/

3. Example
Checkout Payment Inventory Shipping

4. Distributed systems

5. Event-Driven
Checkout Payment Inventory Shipping
Bus
Order
Placed
Does not
know
recipient
Does not
know
sender
Decentral data
management
Smart endpoints
and dumb pipes
Event: Fact that
happened in the past,
Immutable fact,
0..n recepients
Order
Placed
Customer
status
changed
Does know
event type…

6. End-to-end capabilities using event flows?
InventoryPayment ShippingCheckout
Order
placed
Payment
received
Goods
fetched
Goods
shipped

7. Shipping
Goods
shipped
End-to-end capabilities using event flows?
InventoryPaymentCheckout
Order
placed
Payment
received
Goods
fetched
Please fetch
the goods
before waiting
for payment
Some
customers can
pay via invoice
…

8. Some requirements don‘t fit anywhere… What are we missing?
Checkout Payment Inventory Shipping

9. InventoryPayment ShippingCheckout
Bus
Order
Order
Placed
Retrieve
Payment
Order
Placed
Event: Fact,
happened in the past,
immutable,
0..n recepients
Let‘s make our core capability transparent – as a dedicated service
Command: Intent,
1 recipient.

10. Commanding is important!
InventoryPayment ShippingCheckout
Bus
Order
Placed
Event: Fact,
happened in the past,
immutable,
0..n recepients
Retrieve
Payment
Command: Intent,
1 recipient.
Fetch
Goods
Ship
Goods
Order
Order
Placed
Retrieve
Payment
Does not
know
sender
Just knows
command
type…
Dangerous?

11. Some things in life
take time

12. A customer can
update an expired
credit card within
two weeks before we
cancel his order
„

13. Payment
requires
state handling
Order

14. Pass around state
as „routing slip“
Persist state with
Entity, Actor, …
State machine
How to
implement?
DIY
DIY

15. State machine
Persistent thing
(Entity, Actor, …)
Routing
slip
CADENCE
Baker

16. State machines solve some hard developer problems
Monitoring &
Operations
Handling of time &
timeouts
Retry
Visibility &
Reporting
Versioning
Compensation
Message correlation &
deduplication
Performance &
scalability

17. Distributed systems

18. State machines solve some hard developer problems
Monitoring &
Operations
Handling of time &
timeouts
Retry
Visibility &
Reporting
Versioning
Compensation
Message correlation &
deduplication
Performance &
scalability

19. Bpmn.createProcess("order").executable()
//...
.sendTask().name("Retrieve payment").camundaClass(RetrievePayme
.receiveTask().name("Payment received").message("PaymentReceive
//...
{
"name": "retrieve_payment",
"tasks": [ {
"name": "Retrieve Payment",
"taskReferenceName": "payment",
"type": "SIMPLE",
...
Do you prefer coded or graphical DSLs?
* BPMN - ISO notation for modeling and
executing long-running processes and flows

20. Do you need a timeout?

21. Do you need a compensation?*

22. BPM?

23. Flows done right
Developer friendly Lightweight &
composable
BizDevOps

26. More complex flows - transparent and directly executable

27. Focus on long-running behaviour - requiring state

28. Specifying and testing long-running behaviour

29. A visual test report for example #1 (Balance = 50, Amount = 70)

30. A visual test report for example #3 (Balance = 50, Amount = 30)

31. The binding strategy uses the step only when required

32. Living documentation for long-running behaviour

33. Flows done right
Developer friendly Lightweight &
composable
BizDevOps

34. Payment
Flows are owned by services
Order
Distributed
orchestration

35. Order
Order
Order
Order
Architecture
Order
Engine A
Payment
Engine B
Monitoring
Human Task
Management
Coarse grained
central
monitoring
Fine grained
monitoring &
operations
(per context)
DevOps
Tec
Ops Biz
Ops
Central

36. Example
InventoryPaymentOrder ShippingCheckout Monitor
https://github.com/flowing/flowing-retail/

37. Live hacking

38. Operational visibility in monitoring – possibly end-to-end

39. Mitigate tight
coupling
Consider core
capabilities
Leverage state
machines
Decentralize

40. Thank you!

41. Code online:
https://github.com/flowing
Slides & Blog:
https://bernd-ruecker.com
https://plexiti.com
With thoughts from http://flowing.io
@berndruecker | @martinschimak
https://www.infoq.com
/articles/microservice-
event-choreographies

42. Images licensed from iStock
no attribution required
All icons licensed from Noun Project
no attribution required