DON'T FOCUS ON THE THINGS
the nouns
the domain objects
FOCUS ON WHAT HAPPENS
the verbs
the events
Slide 19
Slide 19 text
When you start modeling events,
it forces you to think about the
behavior of the system,
as opposed to thinking about
structure inside the system.
— Greg Young
Slide 20
Slide 20 text
LET THE
EVENTS DEFINE
THE BOUNDED CONTEXT
Slide 21
Slide 21 text
EVENTS REPRESENT FACTS
Slide 22
Slide 22 text
To condense fact from
the vapor of nuance
— Neal Stephenson, Snow Crash
Slide 23
Slide 23 text
WHAT ARE THE FACTS?
Slide 24
Slide 24 text
TRY OUT
EVENT STORMING
Slide 25
Slide 25 text
UNDERSTAND HOW FACTS ARE CAUSALLY RELATED
HOW FACTS FLOW IN THE SYSTEM
Slide 26
Slide 26 text
THINK IN TERMS OF
CONSISTENCY BOUNDARIES
Slide 27
Slide 27 text
WE NEED TO
CONTAIN MUTABLE STATE &
PUBLISH FACTS
Slide 28
Slide 28 text
AGGREGATE
㱺 UNIT OF CONSISTENCY
㱺 UNIT OF FAILURE
Slide 29
Slide 29 text
PRACTICE
REACTIVE DESIGN
Slide 30
Slide 30 text
REACTIVE PROGRAMMING
VS
REACTIVE SYSTEMS
Slide 31
Slide 31 text
REACTIVE PROGRAMMING
CAN HELP US MAKE THE
INDIVIDUAL INSTANCE
HIGHLY PERFORMANT & EFFICIENT
Slide 32
Slide 32 text
GO
ASYNCHRONOUS
Slide 33
Slide 33 text
ASYNCHRONOUS
& NON-BLOCKING
- MORE EFFICIENT USE OF RESOURCES
- MINIMIZES CONTENTION ON SHARED
RESOURCES
Slide 34
Slide 34 text
ALWAYS APPLY BACKPRESSURE
A FAST SYSTEM
SHOULD NOT OVERLOAD
A SLOW SYSTEM
Slide 35
Slide 35 text
BACKPRESSURE
Slide 36
Slide 36 text
LET'S APPLY REACTIVE PROGRAMMING TO OUR MICROLITHS
Slide 37
Slide 37 text
WE'RE GETTING THERE, BUT WE STILL HAVE A
SINGLE INSTANCE MICROSERVICE
㱺 NOT SCALABLE
㱺 NOT RESILIENT
Slide 38
Slide 38 text
REACTIVE SYSTEMS
CAN HELP US BUILD
DISTRIBUTED SYSTEMS THAT ARE
ELASTIC & RESILIENT
Slide 39
Slide 39 text
REACTIVE SYSTEMS ARE BASED ON
ASYNCHRONOUS
MESSAGE-PASSING
Slide 40
Slide 40 text
ALLOWS DECOUPLING IN
SPACE
AND
TIME
Slide 41
Slide 41 text
ALLOWS FOR LOCATION TRANSPARENCY
ONE COMMUNICATION ABSTRACTION ACROSS ALL DIMENSIONS OF SCALE
CORE 㱺 SOCKET 㱺 CPU 㱺
CONTAINER 㱺 SERVER 㱺 RACK 㱺
DATA CENTER 㱺 SYSTEM
Slide 42
Slide 42 text
SELF-HEALING THROUGH BULKHEADING
Slide 43
Slide 43 text
SELF-HEALING THROUGH SUPERVISION
Slide 44
Slide 44 text
MICROSERVICES
COME AS SYSTEMS
Slide 45
Slide 45 text
EACH MICROSERVICE
NEEDS BE DESIGNED AS
A DISTRIBUTED SYSTEM
A MICROSYSTEM
Slide 46
Slide 46 text
WE NEED TO MOVE
FROM MICROLITHS
TO MICROSYSTEMS
Slide 47
Slide 47 text
SEPARATE THE
STATELESS BEHAVIOR
FROM THE
STATEFUL ENTITY
TO SCALE THEM INDIVIDUALLY
Slide 48
Slide 48 text
SCALING (STATELESS) BEHAVIOR
IS EASY
Slide 49
Slide 49 text
SCALING (STATEFUL) ENTITIES
IS HARD
Slide 50
Slide 50 text
THERE IS NO SUCH THING AS A
"STATELESS" ARCHITECTURE
IT'S JUST SOMEONE ELSE'S PROBLEM
Slide 51
Slide 51 text
REACTIVE
MICROSYSTEM
Slide 52
Slide 52 text
PRACTICE
EVENT-BASED
PERSISTENCE
Slide 53
Slide 53 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
Slide 54
Slide 54 text
The truth is the log.
The database is a cache of a
subset of the log.
— Pat Helland
Slide 55
Slide 55 text
EVENT LOGGING
FOR SCALABLE PERSISTENCE
Slide 56
Slide 56 text
CRUD
IS DEAD
Slide 57
Slide 57 text
EVENT SOURCING
A CURE FOR THE CARDINAL SIN
Slide 58
Slide 58 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
Slide 59
Slide 59 text
THE LOG
IS A DATABASE OF THE PAST
NOT JUST A DATABASE OF THE PRESENT
Slide 60
Slide 60 text
EVENT LOGGING AVOIDS THE INFAMOUS
OBJECT-RELATIONAL
IMPEDENCE MISMATCH
Slide 61
Slide 61 text
UNTANGLE THE
READ & WRITE
MODELS WITH
CQRS
Slide 62
Slide 62 text
ADVANTAGES OF USING CQRS:
1. RESILIENCE
2. SCALABILITY
3. POLYGLOT
PERSISTENCE
Slide 63
Slide 63 text
USE
EVENT SOURCING
AND
EVENT STREAMING
Slide 64
Slide 64 text
HOW CAN WE
COORDINATE WORK
ACROSS AGGREGATES?
Slide 65
Slide 65 text
EVENT-DRIVEN
WORKFLOW
Slide 66
Slide 66 text
BUT WHAT ABOUT
TRANSACTIONS?
Slide 67
Slide 67 text
Two-phase commit is the
anti-availability protocol.
— Pat Helland
Slide 68
Slide 68 text
In general,
application developers
simply do not implement
large scalable
applications
assuming distributed
transactions.
— Pat Helland
Slide 69
Slide 69 text
USE A PROTOCOL OF
GUESS.
APOLOGIZE.
COMPENSATE.
Slide 70
Slide 70 text
IT'S HOW THE
WORLD WORKS
Slide 71
Slide 71 text
USE SAGAS
NOT DISTRIBUTED TRANSACTIONS
Slide 72
Slide 72 text
No content
Slide 73
Slide 73 text
IN SUMMARY
1. Don't build Microliths
2. Microservices come in (distributed) systems
3. Microservices come as (micro)systems
4. Embrace the Reactive principles
5. Embrace Event-first DDD & Persistence
6. Profit!
Slide 74
Slide 74 text
TRY THE
LAGOM
MICROSERVICES FRAMEWORK
POWERED BY AKKA & PLAY
LAGOMFRAMEWORK.COM
Slide 75
Slide 75 text
LEARN MORE
DOWNLOAD MY BOOK FOR FREE AT:
BIT.LY/REACTIVE-MICROSYSTEMS