6. Consistency
● Problem: Decentralized Data Management
● No silver bullet
● 2PC is not a good solution for Microservices
● Need consistent(Eventual) operations between Multiple Microservices over different resources
○ Ex: Order/Payment/Mail/Shipment etc
M1 M2 M2 M3 M4 M5
Ext
ServiceRDBMS NoSQL Graph
Operation
Entity A Version2 Entity B Version2 External Version2Entity C Version1
8. Event Driven Design
● Create and publish event whenever data change happens
● Endpoints can be triggered via rest or Events
● Event Channel to make communication between microservices
Event Channel
Order
Microservice
Payment
Microservice
Shipment
Microservice
Mail
Microservice
OrderCreated
OrderProcessed
OrderProcessed
PaymentProcessed PaymentProcessed
9. Entities vs Events
Account 1, +50
Account 1, +150
Account 2, +300
Account 1, -100
Account
Number
Balance Description
1 100 Bank A
2 500 Bank B
….
Table: Account
Events: Account
….
Account 2, +200
….
10. Event Sourcing
● No single entity record
● Entity consist of or calculated with Events
● It's like Audit log
● Easily negate failed commands for operations
Stock
Microservice
Stock1 Created 10 items
Stock1 Sold 2 item
Stock1 Sold 5 item
Stock2 Created 100 items
StockCreatedRecord
Events together = Stock1 3 Items
Event Channel
StockCreatedEvent
ItemSoldRecord
OrderEvents
Stock Command
11. Stock1 Sold 5 item
Event Sourcing (Missing)
● How to Update Data (Events?)
● How to Query Data
○ Do we need Entity or View?
Stock1 Sold 2 item
Stock1 Sold 5 item
Stock2 Created 100 items
Calculations….
Stock1 Created 10 items
Stock1 Sold 2 item
Stock2 Created 100 items
Stock1 Sold 5 item
Stock1 Sold 5 item
12. Microservice
Command Query Responsibility Segregation(CQRS)
● Different sides for Read/Write
● Commands side is based
Aggregates/Aggregate Roots
● Aggregate is bounded concept of
Business value (may span multiple
microservice)
Store
Command Model
Query Model
13. Applied: Event Sourcing
● Cassandra: as Event DB
○ Collect Events to describe Entities
● Kafka: Event Channel
○ Publish Consume events
● For Events between microservices we'll use Event
publish/subscribe
Order1 Shipped
Order2 Created
Event Records for Order1= EntityOrder1
Order1 Created
Order1 Processed
Order
Microservice
Payment
Microservice
Event ChannelEvent
Channel
14. Microservice
Applied: CQRS
● Command Side: Commands are described state change for Entity
● Query Side: Calculates result of recorded events for each entity record when queried.
● Snapshot: Reduces number of events applied in Query
Cassandra
or RDBMS
(Events,
Snapshots)
Store Events
Command 1
Command 2
Command 2
Query
Query Events
Calculate States
Commands
Queries
15. Snapshots (CQRS/ES)
● Reduce events calculated in Query Side
● All Finished(means Completed in time, Finished Aggregates etc) will be calculated and stored
Stock1 Created 10 items
Stock1 Sold 2 item
Stock1 Sold 5 item
Stock1 Sold 3 items
Stock1 Added 15 item
Events together = Stock1 15 Items
Snapshot Table
Event
Channel
Stock1 Entity Stock
Microservice
Listen
16. DEMO
● Order Service - Payment Service - Stock Service
○ Order Create
○ Order Process
■ Reduce Stock
■ Issue Payment
● See Evented DB
● See Command and Query
● See Operation Store (Other examples besides happy path will be added)
● https://github.com/kloiasoft/eventapis -> api and samples
