Skip to main content

Clear Responsibilities for Parts of the Data

Context​

Microservices are used or are being adopted. The data model was decentralized. The storage area per service was isolated to a certain degree.

Problem​

  • Data updates are conducted on the same data at multiple places in the system. These concurrent writes lead to inconsistencies when synchronizing the data.

Solution​

Introduce clear responsibilities for each part of the data. The resulting owner of a piece of data is the only microservice allowed to create, update, or delete the data. Other microservices can have their own read-only copies of the data (potentially adapted to their view on the data model). They can also manipulate their local copy of the data at will. However, they must not update the original data.

Usually, there is no global data model since each microservice has its individual view on the data entities (see decentralize conceptual models). Still, if a global view on the data is maintained, consider to manage responsibilities for data models at the attribute level and not the entity level.

With the introduction of strict data ownership, we remove the risk of data inconsistencies introduced by multiple microservices writing on the same data concurrently. However, instances of a microservice can still write concurrently on the data they own. Consistency has to be ensured by the underlying data storage technology that all instances share.

Maturity​

Proposed, requires evaluation.

Sources of Evidence​

L5:

  • bounded context => data frequently used in single microservice is owned by another
  • requires creating data sharing and sync primitives
    • to avoid comm overhead caused by data copying which happens during service invocations

L12:

  • Context: example system
  • only ChatService can update/create chat metadata entities
  • other services can only have copies of data they don't own, e.g. for caching
  • should be careful about synchronization with master data as copies could be stale

L14:

  • decentralized responsibility for data across microservices has implications on managing updates
    • => no transactions

L31:

  • Context: migration best practices
  • As part of MP4: Decompose the monolith based on data ownership
  • cohesive data entities are grouped together as a unit and can have a unique owner
    • package each group with business logic into a service
  • entity can modified or created just by its owner (the service)
  • other services can have copies of the entity that they don't own
    • can be stale
    • copies should be synchronized appropriately

L44:

  • Context: IoT platform
  • devices need to capture, transfer, analyse, report, and act on data
  • who owns the data and who should have access to it?

L46:

  • independence of microservices => each microservice stewards the data within its context
  • other microservices allowed to read the data
  • writes only through the service possessing the stewardship of the data
  • Example
    • customer account microservice is data steward for customer accounts
    • other microservices able to access read-only versions of customer account data

L58:

  • Context: Synapse as data replication framework
  • many subscribers to given model, but only one publisher (the owner)
  • only owner can create or delete new instances of model
  • subscribers cannot update data they import from other services
    • only work on their copy, add stuff, etc.
  • Read-only subscription model avoids difficult issues related to concurrent update conflicts from distinct services
    • but handles concurrent updates from different servers from the same service

Interview D:

  • Which part of the system is leading on the data?
    • to avoid inconsistencies in the data
    • past: one system fully leading on its data
    • now: broken down to attribute/row-level
      • e.g. service for orders of private customer segment, other service for other orders, delivery addresses the logistic system, name and address the self-service portal.

Interview F:

  • Need to know principle for data
  • E.g., stored cryptographic keys should not be accessible for everyone
    • or if data is especially valuable in some staleness
    • => should stay within a team or a supplier
    • other teams don't need to have access as they don't need to know the data