Within an enterprise distributed system I have many services - an E-commerce service, a CRM, support desk, finance, billing. Many of these services share common data, such as Customer data.

These services communicate with each other using an Enterprise Service Bus (ESB) to ensure that data in all systems is eventually consistent with one another.

My question is this: Is it better to ensure that only one system can update any one part of data? To have a single source of truth. E.g. Only the billing system can update the Customer's billing information. Only the CRM can update the Customer's contact details?

To me this sounds cumbersome and confusing to locate the correct system for the data that you wish to update. I can see it better to have multiple sources for updates and the ESB communicates these updates to subscribed services.

I can see that some data will have a single source of truth (SSOT) as it would be quite niche, such as Customer's credit card information, for example.

What is an commonly adopted technique for dealing with common data that could potentially be updated from different services? Is a SSOT needed in an enterprise distributed system?

1 Answer 1


The most architecturally sound approach I know of is to put that single source of truth behind a microservice. It is perfectly okay for multiple parts of the system to update that data, as long as they do it through something like a microservice that can ensure it's always done correctly and predictably.

So for instance, Customer data is probably already in a database, but all reads and writes of Customer data should go through a single service whose sole purpose is to provide a limited interface for manipulating Customer data. This provides a common place for things like validation logic and query optimization, and ensures that changes to the data always happen in very specific ways you've thought about in advance and are sure will be okay. For instance, you may provide a deleteCustomer request that ensures all credit card data for that customer also gets deleted when the customer does. This also makes it much easier to change the underlying database tables in the future.

Finding the correct microservice should be no harder than finding the correct database tables, and the microservice's API should be significantly easier to use correctly than a database schema. Also, it should be a very thin wrapper; most of the ones I use and write at work simply map each request to a single SQL statement. More interesting logic like using credit card details to charge someone or setting up delivery of their item belong elsewhere.

  • If I understand your answer correctly, you are talking about a common object model across each service, each needing common validation, which makes perfect sense. However I'm using a different bounded context for each of my disparate services, so a Customer in one context can be quite different to a Customer in another context. In this scenario is there still a need for a SSOT in a distributed system ? Jun 30, 2015 at 10:42
  • Could you be a little more specific about what you mean by "different in another context"? My knee-jerk answer would be either "you have two types of Customer, so you need two SSOTs" or "the differences should be all in the application logic, not part of the Customer object itself", but I'm not sure if that would help much.
    – Ixrec
    Jun 30, 2015 at 11:13
  • A quick example would be a Customer in a helpdesk system would potentially have tickets, whereas a Customer in a ecommerce system would have orders and line items. So yes, they are 2 different types of customers, not exposed to other systems outside their own bounded context. Jun 30, 2015 at 11:36
  • I would consider that data associated with a Customer, but not part of the Customer itself or different types of Customers. The SSOTs/microservices/whatevers for tickets, orders and line items should probably check that they have a valid customer id (which could be as simple as a foreign key constraint), but they should still be separate from the SSOT/microservice/whatever for Customer itself. Otherwise these services would not be very "micro".
    – Ixrec
    Jun 30, 2015 at 11:40
  • 1
    @MrDeveloper So you have significant duplication of data with no way of resolving conflicting data. (You're answer verifies that you do have customer sub-types.) Look at normalizing the sub-types. Caching or replicating sub-type locally in individual sub-systems could make sense.
    – BillThor
    Jun 30, 2015 at 13:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.