Tweet
Tweet

Slide 1

Slide 1 text

How Events Are Reshaping Modern Systems Jonas Bonér @jboner

Slide 2

Slide 2 text

Why Events?

Slide 3

Slide 3 text

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?

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

Do Not Settle For Microliths

Slide 6

Slide 6 text

Do Not Settle For Microliths

Slide 7

Slide 7 text

“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

Slide 8

Slide 8 text

What is an Event?

Slide 9

Slide 9 text

Event “Something that happens.” - Merriam Webster

Slide 10

Slide 10 text

The Nature of Events

Slide 11

Slide 11 text

✴ Events represent Facts of information ➡ Facts are immutable ➡ Facts Accrue - Knowledge can only grow The Nature of Events

Slide 12

Slide 12 text

✴ Events represent Facts of information ➡ Facts are immutable ➡ Facts Accrue - Knowledge can only grow ✴ Events/Facts can be disregarded/Ignored The Nature of Events

Slide 13

Slide 13 text

✴ 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

Slide 14

Slide 14 text

✴ 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

Slide 15

Slide 15 text

✴ 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

Slide 16

Slide 16 text

Event Loop What Makes Event Tick

Slide 17

Slide 17 text

✴ Queue + anonymous Callbacks ✴ The Hollywood principle ✴ At-Most-Once delivery guarantees ✴ Local context only ✴ Sync or AsynC ✴ Limited and quite powerless The Event Loop

Slide 18

Slide 18 text

✴ 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.

Slide 19

Slide 19 text

The Problem With Event Callbacks

Slide 20

Slide 20 text

✴ Ephemeral and anonymous The Problem With Event Callbacks

Slide 21

Slide 21 text

✴ Ephemeral and anonymous ✴ No sane failure model Error Channel - console.log(‘4/0=err’, err) The Problem With Event Callbacks

Slide 22

Slide 22 text

✴ Ephemeral and anonymous ✴ No sane failure model Error Channel - console.log(‘4/0=err’, err) ✴ No composition Signature: Input => Side-effect - (Any => Unit) The Problem With Event Callbacks

Slide 23

Slide 23 text

✴ 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 The Problem With Event Callbacks

Slide 24

Slide 24 text

✴ 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 The Problem With Event Callbacks

Slide 25

Slide 25 text

✴ 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

Slide 26

Slide 26 text

https://techbrunch.gousto.co.uk/2016/04/22/callback-hell/

Slide 27

Slide 27 text

No content

Slide 28

Slide 28 text

✴ Patterns Observer, Pub-Sub, Broadcast, … ✴ Futures & PRomises ✴ Dataflow Variables ✴ Stream Processing ✴ Event-driven Microservices ✴ FaaS We Need High Level Abstractions

Slide 29

Slide 29 text

Unified Event Driven Abstractions Powered By Message Driven Fabric Ladder of abstraction

Slide 30

Slide 30 text

Unified Event Driven Abstractions Powered By Message Driven Fabric Network Boundary Ladder of abstraction

Slide 31

Slide 31 text

Unified Event Driven Abstractions Powered By Message Driven Fabric Network Boundary Ladder of abstraction

Slide 32

Slide 32 text

Unified Event Driven Abstractions Powered By Message Driven Fabric Network Boundary Ladder of abstraction

Slide 33

Slide 33 text

Unified Event Driven Abstractions Powered By Message Driven Fabric Unified API (Event-driven Microservices, Patterns, Streams, Futures, FaaS,…) Network Boundary Ladder of abstraction

Slide 34

Slide 34 text

Unified Event Driven Abstractions Powered By Message Driven Fabric Unified API (Event-driven Microservices, Patterns, Streams, Futures, FaaS,…) Network Boundary Event 1 Ladder of abstraction

Slide 35

Slide 35 text

Unified Event Driven Abstractions Powered By Message Driven Fabric Unified API (Event-driven Microservices, Patterns, Streams, Futures, FaaS,…) Local Event Loop Network Boundary Event 1 Ladder of abstraction

Slide 36

Slide 36 text

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 1 Ladder of abstraction

Slide 37

Slide 37 text

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 1 Ladder of abstraction

Slide 38

Slide 38 text

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 Ladder of abstraction

Slide 39

Slide 39 text

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 Ladder of abstraction

Slide 40

Slide 40 text

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 Ladder of abstraction

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

Mutable State Needs To Be Contained And Non Observable

Slide 45

Slide 45 text

Publish Facts To Outside World

Slide 46

Slide 46 text

Event Stream

Slide 47

Slide 47 text

Event Stream Use The as the integration fabric

Slide 48

Slide 48 text

Event Driven Services

Slide 49

Slide 49 text

Event Driven Services

Slide 50

Slide 50 text

Event Driven Services Command

Slide 51

Slide 51 text

Event Driven Services Command

Slide 52

Slide 52 text

Event Driven Services Command

Slide 53

Slide 53 text

Event Driven Services Command Event Event Stream

Slide 54

Slide 54 text

Event Driven Services Command Event Event Event Event Stream

Slide 55

Slide 55 text

Event Driven Services Command Event Event Event Event Stream

Slide 56

Slide 56 text

Event Driven Services Command Event Event Event Event Stream

Slide 57

Slide 57 text

Event Driven Services Command Event Event Event Event Stream

Slide 58

Slide 58 text

Event Driven Services Command Event Event Event Event Stream

Slide 59

Slide 59 text

Event Driven Services Eventual Consistency Command Event Event Event Event Stream

Slide 60

Slide 60 text

Event Driven Services Eventual Consistency Command Event Event Event Event Stream

Slide 61

Slide 61 text

Eventual Consistency

Slide 62

Slide 62 text

Eventual Consistency No One Wants It’s a necessery evil

Slide 63

Slide 63 text

But Relax It Is How The World Works

Slide 64

Slide 64 text

Information Has Latency

Slide 65

Slide 65 text

Information Is Always From the Past

Slide 66

Slide 66 text

Welcome To The Wild Ocean Of Non Determinism Distributed Systems

Slide 67

Slide 67 text

“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

Slide 68

Slide 68 text

Exploit Reality

Slide 69

Slide 69 text

Exploit Reality We need to In our design

Slide 70

Slide 70 text

Events Can Lead To Greater Certainty

Slide 71

Slide 71 text

Events Can Help Us Craft Autonomous Islands Of Determinism

Slide 72

Slide 72 text

No content

Slide 73

Slide 73 text

What does it mean to be Automonous?

Slide 74

Slide 74 text

From greek: Auto-nomos ✴ Auto meaning self ✴ Nomos meaning Law Autonomy

Slide 75

Slide 75 text

Promise Theory

Slide 76

Slide 76 text

Promise Theory Let Lead the way

Slide 77

Slide 77 text

✴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

Slide 78

Slide 78 text

“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

Slide 79

Slide 79 text

Benefits of Thinking in Promises

Slide 80

Slide 80 text

✴ 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

Slide 81

Slide 81 text

✴ 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

Slide 82

Slide 82 text

“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.

Slide 83

Slide 83 text

Events First Design Drives Autonomy

Slide 84

Slide 84 text

Events First Domain Driven Design

Slide 85

Slide 85 text

“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)

Slide 86

Slide 86 text

✴ Don’t focus on the things The Nouns The Domain Objects ✴ Focus on what happens The Verbs The Events

Slide 87

Slide 87 text

Mine the Facts

Slide 88

Slide 88 text

No content

Slide 89

Slide 89 text

Event Storming

Slide 90

Slide 90 text

Event Driven Design

Slide 91

Slide 91 text

✴ IntentS ➡ Communication ➡ Conversations ➡ Expectations ➡ Contracts ➡ Control Transfer Event Driven Design

Slide 92

Slide 92 text

✴ IntentS ➡ Communication ➡ Conversations ➡ Expectations ➡ Contracts ➡ Control Transfer Event Driven Design ✴ Facts ➡ State ➡ History ➡ Causality ➡ Notifications ➡ State Transfer

Slide 93

Slide 93 text

✴ IntentS ➡ Communication ➡ Conversations ➡ Expectations ➡ Contracts ➡ Control Transfer Event Driven Design ✴ Facts ➡ State ➡ History ➡ Causality ➡ Notifications ➡ State Transfer Commands

Slide 94

Slide 94 text

✴ IntentS ➡ Communication ➡ Conversations ➡ Expectations ➡ Contracts ➡ Control Transfer Event Driven Design ✴ Facts ➡ State ➡ History ➡ Causality ➡ Notifications ➡ State Transfer Commands Events

Slide 95

Slide 95 text

Event Driven Design

Slide 96

Slide 96 text

✴Commands ➡ Object form of method/Action request ➡ Imperative: CreateOrder, ShipProduct Event Driven Design

Slide 97

Slide 97 text

✴Commands ➡ Object form of method/Action request ➡ Imperative: CreateOrder, ShipProduct ✴Reactions ➡ Represents side-effects Event Driven Design

Slide 98

Slide 98 text

✴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

Slide 99

Slide 99 text

Commands Events vs

Slide 100

Slide 100 text

Commands Events vs 1. All about intent 1. Intentless

Slide 101

Slide 101 text

Commands Events vs 1. All about intent 2. Directed 1. Intentless 2. Anonymous

Slide 102

Slide 102 text

Commands Events vs 1. All about intent 2. Directed 3. Single addressable destination 1. Intentless 2. Anonymous 3. Just happens - for others (0-N) to observe

Slide 103

Slide 103 text

Commands Events vs 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)

Slide 104

Slide 104 text

Commands Events vs 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

Slide 105

Slide 105 text

Commands Events vs 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

Slide 106

Slide 106 text

Let the Events Define the Bounded Context

Slide 107

Slide 107 text

Principles For Promise Theory Driven Protocol Design

Slide 108

Slide 108 text

1. Convergency Promises should reach a desired state, a stable outcome - idempotent behavior Principles For Promise Theory Driven Protocol Design

Slide 109

Slide 109 text

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

Slide 110

Slide 110 text

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

Slide 111

Slide 111 text

✴ Maintains Integrity & consistency ✴ Is our Unit of Consistency ✴ Is our Unit of Failure ✴ Is our Unit of Determinism ✴ Is fully Autonomous The Aggregate

Slide 112

Slide 112 text

Enough Talk Show Me The Code Sample in Java: https://gist.github.com/jboner/4361c710d2e2386be8bddc39edb0528a Sample in Scala: https://gist.github.com/jboner/dea4aa819e127d543d684208d74081b5

Slide 113

Slide 113 text

Enough Talk Show Me The Code Sample in Java: https://gist.github.com/jboner/4361c710d2e2386be8bddc39edb0528a Sample in Scala: https://gist.github.com/jboner/dea4aa819e127d543d684208d74081b5

Slide 114

Slide 114 text

Are we done now? Perhaps. We have come a long way. But events can also be used for: ➡ Persistence ➡ Managing time

Slide 115

Slide 115 text

Event Based Persistence

Slide 116

Slide 116 text

“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)

Slide 117

Slide 117 text

Event Logging The Bedrock

Slide 118

Slide 118 text

Event Sourcing A Cure For the Cardinal Sin

Slide 119

Slide 119 text

“The truth is the log. The database is a cache of a subset of the log.” - Pat Helland Immutability Changes Everything, Pat Helland (2015)

Slide 120

Slide 120 text

Event Sourced Services

Slide 121

Slide 121 text

Happy Path Event Sourced Services

Slide 122

Slide 122 text

Happy Path Event Sourced Services 1) Receive and verify Command (“ApprovePayment”)

Slide 123

Slide 123 text

Happy Path Event Sourced Services 2) Create new Event (“PaymentApproved”) 1) Receive and verify Command (“ApprovePayment”)

Slide 124

Slide 124 text

Happy Path Event Sourced Services 2) Create new Event (“PaymentApproved”) 1) Receive and verify Command (“ApprovePayment”) 3) Append Event to Event Log

Slide 125

Slide 125 text

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

Slide 126

Slide 126 text

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

Slide 127

Slide 127 text

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

Slide 128

Slide 128 text

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

Slide 129

Slide 129 text

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

Slide 130

Slide 130 text

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

Slide 131

Slide 131 text

Event Sourcing

Slide 132

Slide 132 text

Event Sourcing ✴ One single Source of Truth with All history

Slide 133

Slide 133 text

Event Sourcing ✴ One single Source of Truth with All history ✴ Allows for Memory Image - durable in-memory state

Slide 134

Slide 134 text

Event Sourcing ✴ One single Source of Truth with All history ✴ Allows for Memory Image - durable in-memory state ✴ Avoids the Object-relational mismatch

Slide 135

Slide 135 text

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

Slide 136

Slide 136 text

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.)

Slide 137

Slide 137 text

✴ Unfamiliar model ✴ Versioning of events ✴ Deletion of events (legal or moral reasons) Disadvantages Of Using Event Sourcing

Slide 138

Slide 138 text

Events Allow Us To Manage Time

Slide 139

Slide 139 text

“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)

Slide 140

Slide 140 text

But, What is Time Really?

Slide 141

Slide 141 text

Causality How We Make Sense Of The World

Slide 142

Slide 142 text

Time Is the Succession Of Causally Related Events

Slide 143

Slide 143 text

✴ 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

Slide 144

Slide 144 text

Event Sourcing Allows For Time Travel

Slide 145

Slide 145 text

Event Sourcing Allows For Time Travel

Slide 146

Slide 146 text

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

Slide 147

Slide 147 text

“The future is a function of the past.” - A. P. Robertson

Slide 148

Slide 148 text

“The (local) present is a merge function of multiple concurrent pasts.” - me

Slide 149

Slide 149 text

val newLocalPresent = observedPasts. foldLeft(oldLocalPresent) { _ merge _ }

Slide 150

Slide 150 text

We need to explicitly model the local present as facts derived from the merging of multiple concurrent pasts

Slide 151

Slide 151 text

We Can Even Fork the Past ...Or Join Two Distinct Pasts

Slide 152

Slide 152 text

Let Make Our Demo Event Sourced

Slide 153

Slide 153 text

Untangle Your Read and Write Models With CQRS

Slide 154

Slide 154 text

CQRS

Slide 155

Slide 155 text

CQRS

Slide 156

Slide 156 text

CQRS Write Side Model Commands

Slide 157

Slide 157 text

CQRS Write Side Model Write to Event Log Commands

Slide 158

Slide 158 text

CQRS Write Side Model Events Write to Event Log Commands

Slide 159

Slide 159 text

CQRS Write Side Model Events Events Write to Event Log Commands

Slide 160

Slide 160 text

CQRS Read Side Model Write Side Model Events Events Read Data Store Write to Event Log Commands

Slide 161

Slide 161 text

CQRS Read Side Model Write Side Model Events Queries Events Read Data Store Write to Event Log Commands

Slide 162

Slide 162 text

CQRS Read Side Model Write Side Model Events Queries Events Read Data Store Write to Event Log Eventual Consistency Commands

Slide 163

Slide 163 text

Advantages Of Using CQRS

Slide 164

Slide 164 text

✴ Temporal Decoupling Advantages Of Using CQRS

Slide 165

Slide 165 text

✴ Temporal Decoupling ✴ Increased Resilience Advantages Of Using CQRS

Slide 166

Slide 166 text

✴ Temporal Decoupling ✴ Increased Resilience ✴ Increased Scalability Advantages Of Using CQRS

Slide 167

Slide 167 text

✴ Temporal Decoupling ✴ Increased Resilience ✴ Increased Scalability ✴ Allows for Multiple Event subscribers Advantages Of Using CQRS

Slide 168

Slide 168 text

✴ Temporal Decoupling ✴ Increased Resilience ✴ Increased Scalability ✴ Allows for Multiple Event subscribers ✴ Allows for Polyglot Persistence Advantages Of Using CQRS

Slide 169

Slide 169 text

✴ More infrastructure to manage ✴ 2 data models (or more) to maintain ✴ Eventual Consistency Disadvantages Of Using CQRS

Slide 170

Slide 170 text

Key Takeaways

Slide 171

Slide 171 text

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

Slide 172

Slide 172 text

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

Slide 173

Slide 173 text

Learn More Download my latest book for free at: bit.ly/reactive-microsystems