Event Driven Micro Services
Services sharing DB Anti Pattern
Services must be loosely coupled so that they can be developed, deployed and scaled independently
The benefits of this anti pattern are:
> familiarity & straightforward ACID transactions -> data consistency
> A single database is simpler to operate
The drawbacks of this pattern are:
> Development time coupling will slow down development.
> Runtime coupling - services can interfere with one another
> Single database might not satisfy data storage & access requirements of all services
Database Per Service Pattern
Services must be loosely coupled so that they can be developed, deployed and scaled independently
The drawbacks:
> Implementing business transactions that span multiple services is not straightforward
> Implementing queries that join data that is now in multiple databases is challenging
There are various solutions:
> API Composition - the application performs the join rather than the database
> CQRS and the Saga Pattern
Command and Query Responsibility Segregation (CQRS)
CRUD can
> lead to potentially unnecessary updates for certain operations
> affect performance : prevents concurrent updates and implies load of excessive data
> bring security and permission management overhead
CQRS => Separation of concern
Two separate data models:
Query Models read data from store
Command Models write data to store
Allows scaling of read ad write independently
CQRS => dealing with complexity
Use only in bounded context (limited sections of the system)
Event sourcingfor resiliency and eventual consistency with :
- the store of event as a write model
- materialised views as the read-only cache of data
Related Patterns :
- Data Consistency Primer
- Data Partitioning Guidance
- Event Sourcing Pattern
- Materialized View Pattern
Event Sourcing: Stateless append-only store
Every change in state is captured as an event object
> The event store as the source of truth
> Pub / Sub : Events are published by the store and consumed / processed by subscribers
> Time travelling : the history of events can be played at anytime
Application state can be stored using snapshots