Microservices Data Patterns
Microservices data patterns manage data when each service owns its own store but a business process or read needs information from several services. They replace shared database transactions and joins with explicit workflows, messages, and read models.
itDistributed systems, messaging, and integration | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic: Microservices Data Patterns
Microservices data patterns are what happen after each service gets to mind its own database. This is healthy for autonomy and mildly inconvenient for anyone who hoped a cross-service operation was still one giant transaction wearing a fake moustache.
The first important idea is owned data. A service controls its schema and access to the information for its business capability. Other services ask through APIs or react to events. That stops a convenient join from becoming a permanent, invisible promise between teams. It also means a business operation, such as accepting an order, now travels through several local decisions.
That journey is a saga: a sequence of local transactions. Each step advances the work with an event or command. If a later step fails, earlier steps use compensating actions with business meaning. Releasing a reservation is not a database rollback. It is a new action, which is why it needs an owner, a state, and sometimes a human when the world refuses to cooperate.
The second surprise is that publishing an event is part of the transaction problem. A service can commit its change and then fall over before it tells anyone. The transactional outbox writes the change and the event record together, then a publisher sends the record later. The publisher may send it twice, because computers have an unhelpful talent for failing between two bits of bookkeeping. Consumers therefore need idempotent effects.
Reading is its own choice. API composition asks several services at query time and combines their answers. CQRS keeps a materialized read model from events. The first favors current source responses with runtime fan-out. The second favors repeated combined reads, while accepting lag and the need to repair or rebuild a projection.
Read the Introduction for the full data paths, Slides for the compact map, and Cheatsheet when choosing a transaction, publication, or read pattern. Then use the practice worksheet and exercise to make the workflow, failure path, and visible state explicit. That is the whole trick, apart from all the details that turn out to be the trick.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://microservices.io/patterns/data/database-per-service.html
Supports
- Data ownership
- distributed transactions
- API composition
- and CQRS
- https://microservices.io/patterns/data/saga.html
Supports
- Saga local transactions
- coordination
- and compensation
- https://microservices.io/patterns/data/transactional-outbox.html
Supports
- Atomic local state and event record publication
- https://microservices.io/patterns/data/cqrs.html
Supports
- Materialized views and separate query models
- https://doi.org/10.1145/38713.38742
Supports
- The original 1987 saga model for long-lived transactions and compensating transactions
- https://martinfowler.com/eaaDev/EventSourcing.html
Supports
- Event sourcing as a sequence of state changes and a basis for reconstructing state
- https://cqrs.wordpress.com/wp-content/uploads/2010/11/cqrs_documents.pdf
Supports
- CQRS terminology and its relationship to event sourcing
- https://martinfowler.com/articles/microservices.html
Supports
- The 2014 articulation of microservice architecture
- https://martinfowler.com/articles/2014-site-report/
Supports
- The microservices article publication timing and prior 2012 Tech Radar appearance
- https://www.manning.com/books/microservices-patterns
Supports
- The 2018 Microservices Patterns book and its pattern catalog
- https://eventuate.io/docs/manual/eventuate-tram/wip/distributed-data-management.html
Supports
- Saga
- CQRS
- and transactional outbox as distributed data-management patterns
- https://microservices.io/post/sagas/2019/08/04/developing-sagas-part-2.html
Supports
- Transactional outbox use in saga coordination
- https://debezium.io/documentation/reference/stable/transformations/outbox-event-router.html
Supports
- Outbox table capture and event routing
- https://eventuate.io/docs/manual/eventuate-tram/latest/about-eventuate-tram.html
Supports
- Transactional outbox
- saga orchestration
- and CQRS support in Eventuate Tram
- https://docs.axoniq.io/axon-framework-reference/4.11/sagas/implementation/
Supports
- Event-driven saga lifecycle and state management in Axon Framework
- https://unsupported.docs.camunda.io/8.6/docs/components/best-practices/development/dealing-with-problems-and-exceptions/
Supports
- BPMN compensation as saga support for distributed processes
- https://pages.temporal.io/rs/250-WIU-007/images/tech-guide-saga-pattern-made-easy.pdf
Supports
- Workflow-based saga compensation
