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.
How Events
Are Reshaping
Modern Systems
Jonas Bonér
@jboner
Why Events?
1. Events drive autonomy
2. Events help reduce risk
3. Events help you move faster
4. Events Increase Loose coupling
5. Ev...
1. Cloud and multicore architectures
2. Microservices and distributed systems
3. Data-centric applications
4. “We want mor...
Why Now?
1. Cloud and multicore architectures
2. Microservices and distributed systems
3. Data-centric applications
4. “We...
Do Not Settle For
Microliths
Do Not Settle For
Microliths
“Event-Driven Architecture (EDA) is a design paradigm
in which a software component executes in response
to receiving one ...
What is an
Event?
Event
“Something that happens.”
- Merriam Webster
The Nature of Events
✴Events represent Facts of information
➡ Facts are immutable
➡ Facts Accrue - Knowledge can only grow
The Nature of Events
✴Events represent Facts of information
➡ Facts are immutable
➡ Facts Accrue - Knowledge can only grow
✴ Events/Facts can b...
✴Events represent Facts of information
➡ Facts are immutable
➡ Facts Accrue - Knowledge can only grow
✴ Events/Facts can b...
✴Events represent Facts of information
➡ Facts are immutable
➡ Facts Accrue - Knowledge can only grow
✴ Events/Facts can b...
✴Events represent Facts of information
➡ Facts are immutable
➡ Facts Accrue - Knowledge can only grow
✴ Events/Facts can b...
Event Loop
What Makes Event Tick
✴ Queue + anonymous Callbacks
✴ The Hollywood principle
✴ At-Most-Once delivery guarantees
✴ Local context only
✴ Sync or ...
✴ Queue + anonymous Callbacks
✴ The Hollywood principle
✴ At-Most-Once delivery guarantees
✴ Local context only
✴ Sync or ...
✴ Ephemeral and anonymous
✴ No sane failure model
Error Channel - console.log(‘4/0=err’, err)
✴ No composition
Signature: ...
https://techbrunch.gousto.co.uk/2016/04/22/callback-hell/
✴Patterns
Observer, Pub-Sub, Broadcast, …
✴Futures & PRomises
✴Dataflow Variables
✴Stream Processing
✴ Event-driven Micros...
Unified Event Driven Abstractions
Powered By
Message Driven Fabric
Ladder of
abstraction
Unified Event Driven Abstractions
Powered By
Message Driven Fabric
Network Boundary
Ladder of
abstraction
Unified Event Driven Abstractions
Powered By
Message Driven Fabric
Network Boundary
Ladder of
abstraction
Unified Event Driven Abstractions
Powered By
Message Driven Fabric
Network Boundary
Ladder of
abstraction
Unified Event Driven Abstractions
Powered By
Message Driven Fabric
Unified API (Event-driven Microservices, Patterns, Stre...
Unified Event Driven Abstractions
Powered By
Message Driven Fabric
Unified API (Event-driven Microservices, Patterns, Stre...
Unified Event Driven Abstractions
Powered By
Message Driven Fabric
Unified API (Event-driven Microservices, Patterns, Stre...
Unified Event Driven Abstractions
Powered By
Message Driven Fabric
Unified API (Event-driven Microservices, Patterns, Stre...
Unified Event Driven Abstractions
Powered By
Message Driven Fabric
Unified API (Event-driven Microservices, Patterns, Stre...
Unified Event Driven Abstractions
Powered By
Message Driven Fabric
Unified API (Event-driven Microservices, Patterns, Stre...
Unified Event Driven Abstractions
Powered By
Message Driven Fabric
Unified API (Event-driven Microservices, Patterns, Stre...
Unified Event Driven Abstractions
Powered By
Message Driven Fabric
Unified API (Event-driven Microservices, Patterns, Stre...
Unified Event Driven Abstractions
Powered By
Message Driven Fabric
Unified API (Event-driven Microservices, Patterns, Stre...
Unified Event Driven Abstractions
Powered By
Message Driven Fabric
Unified API (Event-driven Microservices, Patterns, Stre...
1. REceive and react to facts (or not), that
are coming its way
2. Publish new facts (as events) to the rest
of the world
...
Mutable State
Needs To Be
Contained
And Non Observable
Publish Facts
To Outside World
Event
Stream
Event
Stream
Use The
as the integration fabric
Event Driven
Services
Event Driven
Services
Event Driven
Services
Command
Event Driven
Services
Command
Event Driven
Services
Command
Event Driven
Services
Command
Event
Event Stream
Event Driven
Services
Command
Event
EventEvent
Event Stream
Event Driven
Services
Command
Event
EventEvent
Event Stream
Event Driven
Services
Command
Event
EventEvent
Event Stream
Event Driven
Services
Command
Event
EventEvent
Event Stream
Event Driven
Services
Command
Event
EventEvent
Event Stream
Event Driven
Services
Eventual
Consistency
Command
Event
EventEvent
Event Stream
Event Driven
Services
Eventual
Consistency
Command
Event
EventEvent
Event Stream
Eventual
Consistency
Eventual
Consistency
No One Wants
It’s a necessery evil
But Relax
It Is How The
World Works
Information
Has Latency
Information Is Always
From the Past
Welcome To The Wild Ocean Of
Non Determinism
Distributed Systems
“In a system which cannot count on
distributed transactions, the
management of uncertainty must be
implemented in the busi...
Exploit
Reality
Exploit
Reality
We need to
In our design
Events Can Lead To Greater
Certainty
Events Can Help Us Craft
Autonomous Islands
Of Determinism
What does it mean to be
Automonous?
From greek: Auto-nomos
✴ Auto meaning self
✴ Nomos meaning Law
Autonomy
Promise
Theory
Promise
Theory
Let
Lead the way
✴Impositions diverge
into unpredictable outcomes
from definite beginnings
Distributed information
Decreased certainty
Conv...
“Autonomy makes information local,
leading to greater certainty and stability.”
“An autonomus component can only
promise i...
Benefits of Thinking in Promises
✴ If a service only promises its own behavior
Then all information needed to
➡ Resolve a conflict
➡ Repair under failure
➡...
✴ If a service only promises its own behavior
Then all information needed to
➡ Resolve a conflict
➡ Repair under failure
➡...
“The first principle of successful
scalability is to batter the consistency
mechanisms down to a minimum.”
- James Hamilto...
Events First Design
Drives Autonomy
Events First
Domain Driven
Design
“When you start modeling events, it
forces you to think about the behavior
of the system. As opposed to thinking
about the...
✴ Don’t focus on the things
The Nouns
The Domain Objects
✴ Focus on what happens
The Verbs
The Events
Mine the
Facts
Event Storming
Event Driven Design
✴ IntentS
➡ Communication
➡ Conversations
➡ Expectations
➡ Contracts
➡ Control Transfer
Event Driven Design
✴ IntentS
➡ Communication
➡ Conversations
➡ Expectations
➡ Contracts
➡ Control Transfer
Event Driven Design
✴ Facts
➡ Stat...
✴ IntentS
➡ Communication
➡ Conversations
➡ Expectations
➡ Contracts
➡ Control Transfer
Event Driven Design
✴ Facts
➡ Stat...
✴ IntentS
➡ Communication
➡ Conversations
➡ Expectations
➡ Contracts
➡ Control Transfer
Event Driven Design
✴ Facts
➡ Stat...
Event Driven Design
✴Commands
➡ Object form of method/Action request
➡ Imperative: CreateOrder, ShipProduct
Event Driven Design
✴Commands
➡ Object form of method/Action request
➡ Imperative: CreateOrder, ShipProduct
✴Reactions
➡ Represents side-effec...
✴Commands
➡ Object form of method/Action request
➡ Imperative: CreateOrder, ShipProduct
✴Reactions
➡ Represents side-effec...
Commands Eventsvs
Commands Eventsvs
1. All about intent 1. Intentless
Commands Eventsvs
1. All about intent
2. Directed
1. Intentless
2. Anonymous
Commands Eventsvs
1. All about intent
2. Directed
3. Single addressable
destination
1. Intentless
2. Anonymous
3. Just hap...
Commands Eventsvs
1. All about intent
2. Directed
3. Single addressable
destination
4. Models personal
communication
1. In...
Commands Eventsvs
1. All about intent
2. Directed
3. Single addressable
destination
4. Models personal
communication
5. Di...
Commands Eventsvs
1. All about intent
2. Directed
3. Single addressable
destination
4. Models personal
communication
5. Di...
Let the Events Define the
Bounded Context
Principles For
Promise Theory Driven
Protocol Design
1. Convergency
Promises should reach a desired state,
a stable outcome - idempotent behavior
Principles For
Promise Theory...
1. Convergency
Promises should reach a desired state,
a stable outcome - idempotent behavior
2. Embracing Failure
Expect t...
1. Convergency
Promises should reach a desired state,
a stable outcome - idempotent behavior
2. Embracing Failure
Expect t...
✴ Maintains Integrity & consistency
✴ Is our Unit of Consistency
✴ Is our Unit of Failure
✴ Is our Unit of Determinism
✴ I...
Enough Talk
Show Me The
Code
Sample in Java: https://gist.github.com/jboner/4361c710d2e2386be8bddc39edb0528a
Sample in Sca...
Enough Talk
Show Me The
Code
Sample in Java: https://gist.github.com/jboner/4361c710d2e2386be8bddc39edb0528a
Sample in Sca...
Are we done now?
Are we done now?
Perhaps. We have come a long way.
Are we done now?
Perhaps. We have come a long way.
But events can also be used for:
Are we done now?
Perhaps. We have come a long way.
But events can also be used for:
➡ Persistence
Are we done now?
Perhaps. We have come a long way.
But events can also be used for:
➡ Persistence
➡ Managing time
Event Based
Persistence
“Update-in-place strikes systems
designers as a cardinal sin: it violates
traditional accounting practices that have
been ...
Event Logging
The Bedrock
Event Sourcing
A Cure For the Cardinal Sin
“The truth is the log.
The database is a cache
of a subset of the log.”
- Pat Helland
Immutability Changes Everything, Pat...
Event
Sourced
Services
Happy Path
Event
Sourced
Services
Happy Path
Event
Sourced
Services
1) Receive and verify Command
(“ApprovePayment”)
Happy Path
Event
Sourced
Services
2) Create new Event
(“PaymentApproved”)
1) Receive and verify Command
(“ApprovePayment”)
Happy Path
Event
Sourced
Services
2) Create new Event
(“PaymentApproved”)
1) Receive and verify Command
(“ApprovePayment”)...
Happy Path
Event
Sourced
Services
2) Create new Event
(“PaymentApproved”)
1) Receive and verify Command
(“ApprovePayment”)...
Happy Path
Event
Sourced
Services
5) Run side-effects
(approve the payment)
2) Create new Event
(“PaymentApproved”)
1) Rec...
SAD Path - recovering from failure
Happy Path
Event
Sourced
Services
5) Run side-effects
(approve the payment)
2) Create n...
SAD Path - recovering from failure
Happy Path
Event
Sourced
Services
5) Run side-effects
(approve the payment)
2) Create n...
SAD Path - recovering from failure
Happy Path
Event
Sourced
Services
5) Run side-effects
(approve the payment)
2) Create n...
SAD Path - recovering from failure
Happy Path
Event
Sourced
Services
5) Run side-effects
(approve the payment)
2) Create n...
Event Sourcing
✴ One single Source of Truth with All history
✴ Allows for Memory Image - durable in-memory state
✴ Avoids ...
✴ Unfamiliar model
✴ Versioning of events
✴ Deletion of events (legal or moral reasons)
Disadvantages
Of Using Event Sourc...
EventsAllow Us To Manage
Time
“Modeling events forces you to have a temporal
focus on what’s going on in the system.
Time becomes a crucial factor of th...
But, What is Time
Really?
Causality
How We Make Sense Of The World
Time Is the Succession Of
Causally Related Events
✴ Event is a snapshot in time
✴ Event ID is an index for time
✴ Event Log is our full history
The database of Our past
The...
Event Sourcing
Allows For
Time Travel
Event Sourcing
Allows For
Time Travel
Event Sourcing
Allows For
Time Travel
✴Replay the log for historic debugging
✴Replay the log for auditing & traceability
✴...
“The future is a function of the past.”
- A. P. Robertson
“The (local) present is a merge function
of multiple concurrent pasts.”
- me
val newLocalPresent = observedPasts.
foldLeft(oldLocalPresent) { _ merge _ }
We need to explicitly model the
local present as
facts derived from the
merging of multiple
concurrent pasts
We Can Even Fork the Past
...Or Join Two Distinct Pasts
Let Make Our Demo
Event Sourced
Untangle Your
Read and Write Models
With CQRS
CQRS
CQRS
CQRS
Write Side Model
Commands
CQRS
Write Side Model
Write to Event Log
Commands
CQRS
Write Side Model
Events
Write to Event Log
Commands
CQRS
Write Side Model
Events
Events
Write to Event Log
Commands
CQRS
Read Side Model
Write Side Model
Events
Events
Read Data Store
Write to Event Log
Commands
CQRS
Read Side Model
Write Side Model
Events
Queries
Events
Read Data Store
Write to Event Log
Commands
CQRS
Read Side Model
Write Side Model
Events
Queries
Events
Read Data Store
Write to Event Log
Eventual
Consistency
Comman...
✴ Temporal Decoupling
✴ Increased Resilience
✴ Increased Scalability
✴ Allows for Multiple Event subscribers
✴ Allows for ...
✴ More infrastructure to manage
✴ 2 data models (or more) to maintain
✴ Eventual Consistency
Disadvantages
Of Using CQRS
Key Takeaways
Key Takeaways
Event driven design helps you to:
✴ Design autonomous services
✴ Move Faster towards a Reactive architecture...
Key Takeaways
Event driven design helps you to:
✴ Design autonomous services
✴ Move Faster towards a Reactive architecture...
Learn More
Download my latest book for free at:
bit.ly/reactive-microsystems
How Events Are Reshaping Modern Systems
How Events Are Reshaping Modern Systems
How Events Are Reshaping Modern Systems
How Events Are Reshaping Modern Systems
How Events Are Reshaping Modern Systems
How Events Are Reshaping Modern Systems
Upcoming SlideShare
Loading in …5
×

How Events Are Reshaping Modern Systems

814 views

Published on

Event-driven architecture and design have been getting a lot of attention in recent years. It’s an old concept that has been around for decades, so why this sudden peak of interest?

In this talk, we will explore the nature of events, what it means to be event-driven, and how we can unleash the power of events. The goal is to arm you with a solid theoretical understanding of how to design an event-driven system, what tools and techniques you can use to reap the most benefit from its design, and perhaps most importantly, what to avoid.

We'll discuss how an event-driven design can help:
- drive autonomy
- reduce risk
- increase certainty
- increase loose coupling
- increase scalability
- increase resilience
- increase traceability

Skeptics should definitely attend.

Published in: Engineering
  • Be the first to comment

How Events Are Reshaping Modern Systems

  1. 1. How Events Are Reshaping Modern Systems Jonas Bonér @jboner
  2. 2. Why Events?
  3. 3. 1. Events drive autonomy 2. Events help reduce risk 3. Events help you move faster 4. Events Increase Loose coupling 5. Events increase stability 6. Events increase scalability 7. Events increase resilience 8. Events increase traceability 9. Events allow for time-travel Why Should you care?
  4. 4. 1. Cloud and multicore architectures 2. Microservices and distributed systems 3. Data-centric applications 4. “We want more, of everything, and we want it now.” - Your Customers
  5. 5. Why Now? 1. Cloud and multicore architectures 2. Microservices and distributed systems 3. Data-centric applications 4. “We want more, of everything, and we want it now.” - Your Customers
  6. 6. Do Not Settle For Microliths
  7. 7. Do Not Settle For Microliths
  8. 8. “Event-Driven Architecture (EDA) is a design paradigm in which a software component executes in response to receiving one or more event notifications.” - Gartner Event Driven Architecture To The Rescue
  9. 9. What is an Event?
  10. 10. Event “Something that happens.” - Merriam Webster
  11. 11. The Nature of Events
  12. 12. ✴Events represent Facts of information ➡ Facts are immutable ➡ Facts Accrue - Knowledge can only grow The Nature of Events
  13. 13. ✴Events represent Facts of information ➡ Facts are immutable ➡ Facts Accrue - Knowledge can only grow ✴ Events/Facts can be disregarded/Ignored The Nature of Events
  14. 14. ✴Events represent Facts of information ➡ Facts are immutable ➡ Facts Accrue - Knowledge can only grow ✴ Events/Facts can be disregarded/Ignored ✴ Events/Facts Can not be retracted (once accepted) The Nature of Events
  15. 15. ✴Events represent Facts of information ➡ Facts are immutable ➡ Facts Accrue - Knowledge can only grow ✴ Events/Facts can be disregarded/Ignored ✴ Events/Facts Can not be retracted (once accepted) ✴ Events/Facts Can not be deleted (once accepted) ➡ Might be needed for legal or moral reasons The Nature of Events
  16. 16. ✴Events represent Facts of information ➡ Facts are immutable ➡ Facts Accrue - Knowledge can only grow ✴ Events/Facts can be disregarded/Ignored ✴ Events/Facts Can not be retracted (once accepted) ✴ Events/Facts Can not be deleted (once accepted) ➡ Might be needed for legal or moral reasons ✴ Events/Facts (new) can invalidate existing Facts The Nature of Events
  17. 17. Event Loop What Makes Event Tick
  18. 18. ✴ Queue + anonymous Callbacks ✴ The Hollywood principle ✴ At-Most-Once delivery guarantees ✴ Local context only ✴ Sync or AsynC ✴ Limited and quite powerless The Event Loop
  19. 19. ✴ Queue + anonymous Callbacks ✴ The Hollywood principle ✴ At-Most-Once delivery guarantees ✴ Local context only ✴ Sync or AsynC ✴ Limited and quite powerless The Event Loop * * Too limited as a general model of computation, and programming model for modern distributed systems. But is a useful building block.
  20. 20. ✴ Ephemeral and anonymous ✴ No sane failure model Error Channel - console.log(‘4/0=err’, err) ✴ No composition Signature: Input => Side-effect - (Any => Unit) ✴ Hard to Debug ✴ Hard to reason about ✴ Leads to Callback hell The Problem With Event Callbacks
  21. 21. https://techbrunch.gousto.co.uk/2016/04/22/callback-hell/
  22. 22. ✴Patterns Observer, Pub-Sub, Broadcast, … ✴Futures & PRomises ✴Dataflow Variables ✴Stream Processing ✴ Event-driven Microservices ✴ FaaS We Need High Level Abstractions
  23. 23. Unified Event Driven Abstractions Powered By Message Driven Fabric Ladder of abstraction
  24. 24. Unified Event Driven Abstractions Powered By Message Driven Fabric Network Boundary Ladder of abstraction
  25. 25. Unified Event Driven Abstractions Powered By Message Driven Fabric Network Boundary Ladder of abstraction
  26. 26. Unified Event Driven Abstractions Powered By Message Driven Fabric Network Boundary Ladder of abstraction
  27. 27. Unified Event Driven Abstractions Powered By Message Driven Fabric Unified API (Event-driven Microservices, Patterns, Streams, Futures, FaaS,…) Network Boundary Ladder of abstraction
  28. 28. Unified Event Driven Abstractions Powered By Message Driven Fabric Unified API (Event-driven Microservices, Patterns, Streams, Futures, FaaS,…) Network Boundary Event 1Ladder of abstraction
  29. 29. Unified Event Driven Abstractions Powered By Message Driven Fabric Unified API (Event-driven Microservices, Patterns, Streams, Futures, FaaS,…) Local Event Loop Network Boundary Event 1Ladder of abstraction
  30. 30. Unified Event Driven Abstractions Powered By Message Driven Fabric Unified API (Event-driven Microservices, Patterns, Streams, Futures, FaaS,…) Local Event Loop Distribution Fabric Network Boundary Event 1Ladder of abstraction
  31. 31. Unified Event Driven Abstractions Powered By Message Driven Fabric Unified API (Event-driven Microservices, Patterns, Streams, Futures, FaaS,…) Local Event Loop Distribution Fabric Distribution Fabric Network Boundary Message Passing Event 1Ladder of abstraction
  32. 32. Unified Event Driven Abstractions Powered By Message Driven Fabric Unified API (Event-driven Microservices, Patterns, Streams, Futures, FaaS,…) Local Event Loop Distribution Fabric Local Event Loop Distribution Fabric Network Boundary Message Passing Event 1Ladder of abstraction
  33. 33. Unified Event Driven Abstractions Powered By Message Driven Fabric Unified API (Event-driven Microservices, Patterns, Streams, Futures, FaaS,…) Local Event Loop Distribution Fabric Local Event Loop Distribution Fabric Network Boundary Message Passing Event 1Ladder of abstraction
  34. 34. Unified Event Driven Abstractions Powered By Message Driven Fabric Unified API (Event-driven Microservices, Patterns, Streams, Futures, FaaS,…) Local Event Loop Distribution Fabric Local Event Loop Distribution Fabric Network Boundary Message Passing Event 1 Event 1Ladder of abstraction
  35. 35. Unified Event Driven Abstractions Powered By Message Driven Fabric Unified API (Event-driven Microservices, Patterns, Streams, Futures, FaaS,…) Local Event Loop Distribution Fabric Local Event Loop Distribution Fabric Network Boundary Message Passing Event 1 Event 1 Reactive Systems is doing the heavy lifting Ladder of abstraction
  36. 36. Unified Event Driven Abstractions Powered By Message Driven Fabric Unified API (Event-driven Microservices, Patterns, Streams, Futures, FaaS,…) Local Event Loop Distribution Fabric Local Event Loop Distribution Fabric Network Boundary Message Passing Event 1 Event 1 Reactive Systems is doing the heavy lifting Ladder of abstraction Reactive Programming
  37. 37. 1. REceive and react to facts (or not), that are coming its way 2. Publish new facts (as events) to the rest of the world 3. Invert the control flow to minimize coupling and increase autonomy Event Driven Services
  38. 38. Mutable State Needs To Be Contained And Non Observable
  39. 39. Publish Facts To Outside World
  40. 40. Event Stream
  41. 41. Event Stream Use The as the integration fabric
  42. 42. Event Driven Services
  43. 43. Event Driven Services
  44. 44. Event Driven Services Command
  45. 45. Event Driven Services Command
  46. 46. Event Driven Services Command
  47. 47. Event Driven Services Command Event Event Stream
  48. 48. Event Driven Services Command Event EventEvent Event Stream
  49. 49. Event Driven Services Command Event EventEvent Event Stream
  50. 50. Event Driven Services Command Event EventEvent Event Stream
  51. 51. Event Driven Services Command Event EventEvent Event Stream
  52. 52. Event Driven Services Command Event EventEvent Event Stream
  53. 53. Event Driven Services Eventual Consistency Command Event EventEvent Event Stream
  54. 54. Event Driven Services Eventual Consistency Command Event EventEvent Event Stream
  55. 55. Eventual Consistency
  56. 56. Eventual Consistency No One Wants It’s a necessery evil
  57. 57. But Relax It Is How The World Works
  58. 58. Information Has Latency
  59. 59. Information Is Always From the Past
  60. 60. Welcome To The Wild Ocean Of Non Determinism Distributed Systems
  61. 61. “In a system which cannot count on distributed transactions, the management of uncertainty must be implemented in the business logic.” - Pat Helland Life Beyond Distributed Transactions - An Apostate’s Opinion, Pat Helland (2007) We Need To Model Uncertainty
  62. 62. Exploit Reality
  63. 63. Exploit Reality We need to In our design
  64. 64. Events Can Lead To Greater Certainty
  65. 65. Events Can Help Us Craft Autonomous Islands Of Determinism
  66. 66. What does it mean to be Automonous?
  67. 67. From greek: Auto-nomos ✴ Auto meaning self ✴ Nomos meaning Law Autonomy
  68. 68. Promise Theory
  69. 69. Promise Theory Let Lead the way
  70. 70. ✴Impositions diverge into unpredictable outcomes from definite beginnings Distributed information Decreased certainty Convergence vs. Divergence of information ✴Promises converge towards a definite outcome from unpredictable beginnings Local information Improved certainty
  71. 71. “Autonomy makes information local, leading to greater certainty and stability.” “An autonomus component can only promise its own behavior.” - Mark Burgess In Search of Certainty, Thinking in Promises - Mark Burgess
  72. 72. Benefits of Thinking in Promises
  73. 73. ✴ If a service only promises its own behavior Then all information needed to ➡ Resolve a conflict ➡ Repair under failure ➡ Is available within the service itself Benefits of Thinking in Promises
  74. 74. ✴ If a service only promises its own behavior Then all information needed to ➡ Resolve a conflict ➡ Repair under failure ➡ Is available within the service itself ✴ Promises remove the need for needless 1. Communication 2. Coordination 3. Consensus Benefits of Thinking in Promises
  75. 75. “The first principle of successful scalability is to batter the consistency mechanisms down to a minimum.” - James Hamilton As transcribed in: Toward a Cloud Computing Research Agenda. SIGACT News, 40(2):68–80, June 2009.
  76. 76. Events First Design Drives Autonomy
  77. 77. Events First Domain Driven Design
  78. 78. “When you start modeling events, it forces you to think about the behavior of the system. As opposed to thinking about the structure of the system.” - Greg Young A Decade of DDD, CQRS, Event Sourcing, Greg Young (Presentation from 2016)
  79. 79. ✴ Don’t focus on the things The Nouns The Domain Objects ✴ Focus on what happens The Verbs The Events
  80. 80. Mine the Facts
  81. 81. Event Storming
  82. 82. Event Driven Design
  83. 83. ✴ IntentS ➡ Communication ➡ Conversations ➡ Expectations ➡ Contracts ➡ Control Transfer Event Driven Design
  84. 84. ✴ IntentS ➡ Communication ➡ Conversations ➡ Expectations ➡ Contracts ➡ Control Transfer Event Driven Design ✴ Facts ➡ State ➡ History ➡ Causality ➡ Notifications ➡ State Transfer
  85. 85. ✴ IntentS ➡ Communication ➡ Conversations ➡ Expectations ➡ Contracts ➡ Control Transfer Event Driven Design ✴ Facts ➡ State ➡ History ➡ Causality ➡ Notifications ➡ State Transfer Commands
  86. 86. ✴ IntentS ➡ Communication ➡ Conversations ➡ Expectations ➡ Contracts ➡ Control Transfer Event Driven Design ✴ Facts ➡ State ➡ History ➡ Causality ➡ Notifications ➡ State Transfer Commands Events
  87. 87. Event Driven Design
  88. 88. ✴Commands ➡ Object form of method/Action request ➡ Imperative: CreateOrder, ShipProduct Event Driven Design
  89. 89. ✴Commands ➡ Object form of method/Action request ➡ Imperative: CreateOrder, ShipProduct ✴Reactions ➡ Represents side-effects Event Driven Design
  90. 90. ✴Commands ➡ Object form of method/Action request ➡ Imperative: CreateOrder, ShipProduct ✴Reactions ➡ Represents side-effects ✴Events ➡ Represents something that has happened ➡ Past-tense: OrderCreated, ProductShipped Event Driven Design
  91. 91. Commands Eventsvs
  92. 92. Commands Eventsvs 1. All about intent 1. Intentless
  93. 93. Commands Eventsvs 1. All about intent 2. Directed 1. Intentless 2. Anonymous
  94. 94. Commands Eventsvs 1. All about intent 2. Directed 3. Single addressable destination 1. Intentless 2. Anonymous 3. Just happens - for others (0-N) to observe
  95. 95. Commands Eventsvs 1. All about intent 2. Directed 3. Single addressable destination 4. Models personal communication 1. Intentless 2. Anonymous 3. Just happens - for others (0-N) to observe 4. Models broadcast (speakers corner)
  96. 96. Commands Eventsvs 1. All about intent 2. Directed 3. Single addressable destination 4. Models personal communication 5. Distributed focus 1. Intentless 2. Anonymous 3. Just happens - for others (0-N) to observe 4. Models broadcast (speakers corner) 5. Local focus
  97. 97. Commands Eventsvs 1. All about intent 2. Directed 3. Single addressable destination 4. Models personal communication 5. Distributed focus 6. Command & Control 1. Intentless 2. Anonymous 3. Just happens - for others (0-N) to observe 4. Models broadcast (speakers corner) 5. Local focus 6. Autonomy
  98. 98. Let the Events Define the Bounded Context
  99. 99. Principles For Promise Theory Driven Protocol Design
  100. 100. 1. Convergency Promises should reach a desired state, a stable outcome - idempotent behavior Principles For Promise Theory Driven Protocol Design
  101. 101. 1. Convergency Promises should reach a desired state, a stable outcome - idempotent behavior 2. Embracing Failure Expect things to go wrong Promises may or may not be kept Principles For Promise Theory Driven Protocol Design
  102. 102. 1. Convergency Promises should reach a desired state, a stable outcome - idempotent behavior 2. Embracing Failure Expect things to go wrong Promises may or may not be kept 3. Autonomy You can’t rely on other services Principles For Promise Theory Driven Protocol Design
  103. 103. ✴ Maintains Integrity & consistency ✴ Is our Unit of Consistency ✴ Is our Unit of Failure ✴ Is our Unit of Determinism ✴ Is fully Autonomous The Aggregate
  104. 104. Enough Talk Show Me The Code Sample in Java: https://gist.github.com/jboner/4361c710d2e2386be8bddc39edb0528a Sample in Scala: https://gist.github.com/jboner/dea4aa819e127d543d684208d74081b5
  105. 105. Enough Talk Show Me The Code Sample in Java: https://gist.github.com/jboner/4361c710d2e2386be8bddc39edb0528a Sample in Scala: https://gist.github.com/jboner/dea4aa819e127d543d684208d74081b5
  106. 106. Are we done now?
  107. 107. Are we done now? Perhaps. We have come a long way.
  108. 108. Are we done now? Perhaps. We have come a long way. But events can also be used for:
  109. 109. Are we done now? Perhaps. We have come a long way. But events can also be used for: ➡ Persistence
  110. 110. Are we done now? Perhaps. We have come a long way. But events can also be used for: ➡ Persistence ➡ Managing time
  111. 111. Event Based Persistence
  112. 112. “Update-in-place strikes systems designers as a cardinal sin: it violates traditional accounting practices that have been observed for hundreds of years.” - jim Gray The Transaction Concept, Jim Gray (1981)
  113. 113. Event Logging The Bedrock
  114. 114. Event Sourcing A Cure For the Cardinal Sin
  115. 115. “The truth is the log. The database is a cache of a subset of the log.” - Pat Helland Immutability Changes Everything, Pat Helland (2015)
  116. 116. Event Sourced Services
  117. 117. Happy Path Event Sourced Services
  118. 118. Happy Path Event Sourced Services 1) Receive and verify Command (“ApprovePayment”)
  119. 119. Happy Path Event Sourced Services 2) Create new Event (“PaymentApproved”) 1) Receive and verify Command (“ApprovePayment”)
  120. 120. Happy Path Event Sourced Services 2) Create new Event (“PaymentApproved”) 1) Receive and verify Command (“ApprovePayment”) 3) Append Event to Event Log
  121. 121. Happy Path Event Sourced Services 2) Create new Event (“PaymentApproved”) 1) Receive and verify Command (“ApprovePayment”) 3) Append Event to Event Log 4) Update internal component state
  122. 122. Happy Path Event Sourced Services 5) Run side-effects (approve the payment) 2) Create new Event (“PaymentApproved”) 1) Receive and verify Command (“ApprovePayment”) 3) Append Event to Event Log 4) Update internal component state
  123. 123. SAD Path - recovering from failure Happy Path Event Sourced Services 5) Run side-effects (approve the payment) 2) Create new Event (“PaymentApproved”) 1) Receive and verify Command (“ApprovePayment”) 3) Append Event to Event Log 4) Update internal component state
  124. 124. SAD Path - recovering from failure Happy Path Event Sourced Services 5) Run side-effects (approve the payment) 2) Create new Event (“PaymentApproved”) 1) Receive and verify Command (“ApprovePayment”) 3) Append Event to Event Log 4) Update internal component state 1) Rehydrate Events from Event Log
  125. 125. SAD Path - recovering from failure Happy Path Event Sourced Services 5) Run side-effects (approve the payment) 2) Create new Event (“PaymentApproved”) 1) Receive and verify Command (“ApprovePayment”) 3) Append Event to Event Log 4) Update internal component state 1) Rehydrate Events from Event Log 2) Update internal component state
  126. 126. SAD Path - recovering from failure Happy Path Event Sourced Services 5) Run side-effects (approve the payment) 2) Create new Event (“PaymentApproved”) 1) Receive and verify Command (“ApprovePayment”) 3) Append Event to Event Log 4) Update internal component state 1) Rehydrate Events from Event Log 2) Update internal component state Memory Image
  127. 127. Event Sourcing ✴ One single Source of Truth with All history ✴ Allows for Memory Image - durable in-memory state ✴ Avoids the Object-relational mismatch ✴ Allows others to Subscribe to state changes ✴ Mechanical sympathy (Single Writer Principle etc.)
  128. 128. ✴ Unfamiliar model ✴ Versioning of events ✴ Deletion of events (legal or moral reasons) Disadvantages Of Using Event Sourcing
  129. 129. EventsAllow Us To Manage Time
  130. 130. “Modeling events forces you to have a temporal focus on what’s going on in the system. Time becomes a crucial factor of the system.” - Greg Young A Decade of DDD, CQRS, Event Sourcing, Greg Young (Presentation from 2016)
  131. 131. But, What is Time Really?
  132. 132. Causality How We Make Sense Of The World
  133. 133. Time Is the Succession Of Causally Related Events
  134. 134. ✴ Event is a snapshot in time ✴ Event ID is an index for time ✴ Event Log is our full history The database of Our past The path to Our present Event Sourcing Allows Us To Model Time
  135. 135. Event Sourcing Allows For Time Travel
  136. 136. Event Sourcing Allows For Time Travel
  137. 137. Event Sourcing Allows For Time Travel ✴Replay the log for historic debugging ✴Replay the log for auditing & traceability ✴Replay the log on failure ✴Replay the log for replication
  138. 138. “The future is a function of the past.” - A. P. Robertson
  139. 139. “The (local) present is a merge function of multiple concurrent pasts.” - me
  140. 140. val newLocalPresent = observedPasts. foldLeft(oldLocalPresent) { _ merge _ }
  141. 141. We need to explicitly model the local present as facts derived from the merging of multiple concurrent pasts
  142. 142. We Can Even Fork the Past ...Or Join Two Distinct Pasts
  143. 143. Let Make Our Demo Event Sourced
  144. 144. Untangle Your Read and Write Models With CQRS
  145. 145. CQRS
  146. 146. CQRS
  147. 147. CQRS Write Side Model Commands
  148. 148. CQRS Write Side Model Write to Event Log Commands
  149. 149. CQRS Write Side Model Events Write to Event Log Commands
  150. 150. CQRS Write Side Model Events Events Write to Event Log Commands
  151. 151. CQRS Read Side Model Write Side Model Events Events Read Data Store Write to Event Log Commands
  152. 152. CQRS Read Side Model Write Side Model Events Queries Events Read Data Store Write to Event Log Commands
  153. 153. CQRS Read Side Model Write Side Model Events Queries Events Read Data Store Write to Event Log Eventual Consistency Commands
  154. 154. ✴ Temporal Decoupling ✴ Increased Resilience ✴ Increased Scalability ✴ Allows for Multiple Event subscribers ✴ Allows for Polyglot Persistence Advantages Of Using CQRS
  155. 155. ✴ More infrastructure to manage ✴ 2 data models (or more) to maintain ✴ Eventual Consistency Disadvantages Of Using CQRS
  156. 156. Key Takeaways
  157. 157. Key Takeaways Event driven design helps you to: ✴ Design autonomous services ✴ Move Faster towards a Reactive architecture ✴ reduce risk when modernizing applications ✴ Balance Certainty and Uncertainty
  158. 158. Key Takeaways Event driven design helps you to: ✴ Design autonomous services ✴ Move Faster towards a Reactive architecture ✴ reduce risk when modernizing applications ✴ Balance Certainty and Uncertainty Event Logging allows you to: ✴ take control of your system’s history ✴ time-travel ✴ Balance Strong and eventual consistency
  159. 159. Learn More Download my latest book for free at: bit.ly/reactive-microsystems

×