0

We have a microservices application and our User management service is the source of truth for user's first and last name. But we also need these in the Reporting service, where we generate reports for the users that should contain their first/last name. Our Billing service also needs these names when sending claims to external providers.

One possible solution that comes to mind is to emit UserCreated/Modified events from the user management service and replicate the names in the billing and reporting service. That would work but as I was made aware, the services should own their data and should not need external data from other services. So would you handle that? Maybe we should rethink our service boundaries but on the other side - how would you name a context that manages users and also bills and also generates reports?

1
  • Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer.
    – Community Bot
    Jun 5, 2023 at 3:06

2 Answers 2

0

That would work but as I was made aware, the services should own their data and should not need external data from other services

Two or more services can hold and manage "copies" (or partial copies) of data coming from other domains (services) and there are good reasons for it. For example

  • Performance: Faster queries.
  • Efficiency: Fewer issues related to interprocess communications.
  • Decoupling: Services and data can go and come; the availability can change quickly.

Source and ownership are not responsibilities necessarily exclusive to a single service. Data is data and belongs to the system (as a whole).

What's exclusive to a service is the authority, the knowledge required to operate with the data. What makes User service valuable is not the data, it's the knowledge. Information and knowledge are not the same thing. A proof of it is that, you can get data from a queue or broker, making these the source of trust, but the only who can tell if the data is valid or not, is the service.

Maybe we should rethink our service boundaries

Maybe.

Microservices can be formed of smaller services, or two domains to be so correlated that worth unifying both into a single one to ease development and management. Nevertheless, this is not the case for Users, Billing and Reports. Their respective business differs considerably from one another.

So would you handle that?

I would analyze the context for which I'm duplicating the data.

By duplicating data into another boundary, we give a new context to this data. The data's lifecycle and the needs for availability or consistency might have changed, the previous rules and policies might not be applicable to new context. E.g. committed invoices are immutable; no change is allowed; no change coming from the User Service should be propagated to committed invoices. In this new context, the user's data is expected to be treated differently than in User Service, because, in essence, they are different data (despite representing the same thing), so the Billing Service will rule the user's data associated with invoices according to the billing service rules, not the user service rules.

1
  • Thanks for the detailed answer. It clarified a lot of things. I guess now it's up to us to make the availability/consistency decision.
    – rqpa93
    Jul 6, 2023 at 22:33
1

You are probably looking for something like Udi Dahan's discussions of data and service boundaries


There are at least two different ways to think about what's going on:

  • User management is the authoritative source for information about customer names; other systems have cached copies of the authoritative data provided by user management.

  • User management is the authoritative source for information about customer names; small components of the user management service are physically deployed with other components to compose other services.


An analogy that I find somewhat helpful for myself: UNECE tracks standardized location codes for shipping destinations around the world. Over time, those codes change, a little bit: new ports become available, others are retired, some change hands.... A report of the "current" official location codes is published on a regular basis.

The bureaucratic processes for managing changes are hidden behind the facade of the UNECE "service"; we don't need to be tightly coupled to them. Instead, we can just use the most recent issue of the codes, which might be several months old (ie: caching).

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.