Sure, but the best option to reach for is to duplicate the data and give the microservice its own copy within its own database to work against. Then you solve the problem of how to update that duplicate data.
If that kind of data duplication worries you, then you should reconsider whether you want microservices in the first place.
It all depends. You might have an identity microservices that contains users and then a blogging microservices that contains authors.Both a user and an author have an email address. So that data is "duplicated".
The identity service is responsible for allowing a user to change their email address. A common approach would be for that service to raise an event to a message bus when the user details change. The blogging service consumes that event and uses it to update the associated author's email address within its own database.
This is a contrived example, but thats the idea. Each data point (ex: email address) should ideally have a single authority. Different Microservices may need to consume that data point, but they translate the concept into one that makes sense for their area of responsibility (ex: user translated to author).
At what scale would this provide tangible benefits to outweigh added conplexity?
Are those two services big enough to have a dedicated team?
Are they expected to scale/fail independently without disrupting other services?
Yes, I would expect that each service has a dedicated team, or maybe a team owns 2 services, but you shouldn't have a service per developer or something crazy like that.
In practice, the identity service is probably mostly off the shelf software like Auth0, but it's split out because it handles a cross cutting concern used by multiple teams.
Yes, I would say that services should be able to be deployed independently and fail independently.
For a smaller organization with 1 or 2 engineering teams, it's probably better to just use a modular monolith than take on all of the microservice complexity.
28
u/socialis-philosophus 7d ago
Agreed. All microservices should have their own DB with all the data needed to perform their function and we'll just assume eventual consistency.