Events in a microservices architecture

EVENTS IN A
MICROSERVICES
ARCHITECTURE
HOW EVENT DRIVEN ARCHITECTURE COMPLEMENTS MICROSERVICES

MICROSERVICES FTW
• Autonomous
• Independently deployable
• Independently scalable
• Loosely coupled
• Fault tolerant
• Distributed

CONSISTENCY IS A CHALLENGE
• In a distributed architecture
• Each service with its own database
• How to maintain a consistent view of the world?
This is not just a microservices problem…

CONSISTENCY IS A CHALLENGE
• Distributed architecture
• Each service with its own database
• How to maintain a consistent view of the world?
This is not just a microservices problem…

THE 8 FALLACIES OF DISTRIBUTED SYSTEMS
• The network is reliable – calls over the network will fail
• Latency is zero – calls over the network take longer
• Bandwidth is infinite – bandwidth may limit or delay data movement
• The network is secure – you cannot trust all requests
• Topology doesn't change – constant topology changes require sophisticated routing and service
discovery
• There is one administrator – systems must be loosely coupled with sophisticated monitoring
• Transport cost is zero – marshalling carries a cost
• The network is homogeneous – different systems have different interfaces, protocols, data
representations
…. Distributed systems are HARD

API’S HAVE DRAWBACKS
• What happens if a service is offline (e.g. network partition)?
• Can build in redundancy, but:
• Redundancy doesn’t guarantee consistency
• Redundancy can be expensive
• Need complicated clustering protocols
• Need complicated consistency or cache-management protocols

OPTION: REDUNDANCY
Customer Inventory
Payments
Logistics
Marketing Orders
• Complicated protocols to coordinate services
• Sharding, master/slave, failover, etc
• Need to maintain consistency across redundant copies

OPTION: CACHING
Customer Inventory
PaymentsLogistics
Marketing Orders
• The two hardest problems in computer science
• Naming things
• Cache invalidation
• You need protocols to maintain consistency between master and cache

OPTION: OPERATIONAL
DATA STORE
Customer Inventory
PaymentsLogistics
Marketing Orders
• Each service holds a copy of the data it needs to do its work
• How to maintain consistency across those copies?

CAP THEOREM
Consistency
Availability Partition Tolerance
Choose any two…
CAP THEOREM
Consistency
Availability Partition Tolerance
Choose any two…

THERE ARE THREE TYPES OF SERVICE INTERACTION
• Command – action to change the state of a resource
• Query – request to give the current state of a resource
• Event – notify a change in state for a resource
• Events are often asynchronous (but not always – e.g. an RSS feed is a list of events obtained by query)
An event is a notification that something has happened

Command /
Query
Event
Interaction Style Synchronous Asynchronous
Consistency STRONG EVENTUAL
Temporal coupling HIGH LOW
Consumer coupling HIGH LOW
Visibility / Traceability GOOD POOR
Security BETTER WORSE
COMMANDS, QUERIES & EVENTS – TRADE-OFFS
Consider these trade-offs when designing
process coordination:
• Orchestration vs
• Choreography
Orchestration provides better visibility &
strong consistency at the cost of tighter
coupling.
Choreography is more loosely coupled but
has poor visibility and only guarantees
eventual consistency.

Active
Create order
Add itemRemove item
Add shipping address
Confirmed
Payment
accepted
Cancelled
Payment
declined
Quoted
Offer payment
Operation Command Event
Create order POST /orders Order created
Add item POST /orders/7e15449c/items Item added
Remove item DELETE /orders/7e15449c/items/3 Item removed
Add address PUT /orders/7e15449c
Offer payment POST /payments
Pmnt accepted
Pmnt declined
Order confirmed
Cancel order DELETE /orders/7e15449c Order cancelled
COMMANDS & EVENTS

Customer
InventoryPayments
Logistics
Marketing
Orders
BOOKSTORE EVENTS
Order created
Item added/removed
Order Confirmed
Payment confirmed
Payment declined
Order shipped
Order delivered
Order returned
Customer logged-in
Customer logged-out
Inventory low
Out of stock
Inventory replenished
Publisher Events Subscribers
Offers
Publisher Events Subscribers

EVENT SOURCING
A pattern where you derive the current state of a resource from its
history (ordered sequence of events).
Useful because events are immutable – means you can recover
the current state at any point in time.
Event Type Order ID Item ID
Add Item 7e15449c 5707255e
Add Item 7e15449c 491addd0
Confirm order 7e15449c
Create order 85c6ce51
Add item 85c6ce51 5707255e
Confirm order 85c6ce51
Order Stream Item ID Count
5707255e 6
491addd0 50
Item ID Count
5707255e 5
491addd0 49
Item ID Count
5707255e 4
491addd0 49
Inventory
Event Type Item ID
Low inventory 5707255e

DESIGN & MANAGE STREAMS LIKE APIS
• Events and APIs are complementary
• Manage your events in the same way that
you manage APIs
• Think about developer experience for event
streams consumers
• Make streams discoverable and self-service
• Design event streams “outside in”
• Implement version and lifecycle management
for streams
• Async API is an opensource project which
brings API concepts to event streams
https://asyncapi.io

CONCLUSION
• You have three awesome tools in your distributed systems tool-box: commands, queries and events
• Events provide loose-coupling at the cost of eventual consistency
• Events are a great way to communicate state across bounded contexts (e.g. domain boundaries)
• Events help communicate state across your information landscape – leads to better resilience and
evolvability
• Use commands and queries to provide strong consistency at the risk of tighter coupling

Events in a microservices architecture

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Events in a microservices architecture

Similar to Events in a microservices architecture (20)

More from Saul Caganoff

More from Saul Caganoff (7)

Recently uploaded

Recently uploaded (20)

Events in a microservices architecture