Single source of truth within an enterprise distributed system

Question

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?

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.