This document discusses microservices architecture with CQRS and event sourcing. It describes microservices as independently deployable services with private databases. The challenge is distributed transactions across services. Event-driven architecture addresses this by having services publish and subscribe to events on state changes. Event sourcing persists object states as sequences of events stored in an event store. The event store delivers events to subscribers. CQRS separates read and write functions, with writes publishing domain events and reads consuming events independently. Using CQRS and event sourcing together provides scalability, simplicity, flexibility and responsiveness to business needs. Apache Kafka can be used to implement the event store.

1. Microservices Architecture
With CQRS and Event Source

2. Microservices
• An architecture that structures the application a set of loosely coupled,
collaborative services.
• Services can be developed and deployed independently of one another. Each
service has its own database in order to be decoupled from other services

3. Example: e-commerce application

4. The problem with Microservices:Distributed
data Management
• Each service has own private database[SQL or NOSQL]
• Transactions that update business entities that are owned by multiple services is
challenge.

5. Solution to Distributed transaction in
Microservices
• Event-driven architecture
– A service publish events when something notable happen(create, update, delete)
– Other services subscribe those events.
– In response to an event it might updates its state or publish more events

6. Event Sourcing
• Solution is to use event source

7. Event Sourcing
• Event sourcing uses event-centric approach to persistence business object states.
• A business object is persisted by storing a sequence of state changing events.
Whenever an object’s state changes, a new event is appended to the sequence of
events.
• Example: Order Service stores an Order by persisting its state changing events:
Created, Approved, Shipped, Cancelled. Each event would contain sufficient data
to reconstruct the Order’s state.

8. Event Store
• Events are persisted in a event store as database of events.
• It behaves like a message broker.
• Each event that is persisted in the event store is is delivered by the event store to
all interested subscribers.

9. CQRS
Command and Query Responsibility Segregation
- CQRS is an architectural design pattern for developing software whereby the bits
of the system that are responsible for changing the system’s state ( the write-parts)
are physically separated from the bits of the system that manage views(the read-
parts).
- This is in contrast to CRUD architecture where traditionally the same component
has the responsibility for both reads( the views) and the writes (the state changes)

10. Why CQRS
• Scalability
– Read-side is separate
from write-side, So
each can be scaled
and performance-
optimized
independently
• Simplicity
– Write-model and the
read model can be
different
• Flexibility
– Clear Separation of
methods that change
the state from the
methods that view the
state, makes change
simpler and can be
made with more
confidence
• Business Focus
– Application are
more responsive to
change and
cheaper to
maintain

11. CQRS and ES together

12. Apache Kafka for CQRS and ES

13. • Thanks