Currently when I build applications, I build them as one big monolithic application such that everything resides in a single compiled assembly and the data resides in one single SQL database (with some redis/elasticsearch used as support). This works relatively well for my purposes, but I would like to move towards designing micro service architectures. However I have a hard time understanding how any relational integrity is maintained when your services/databases are spread across several servers.
Observe the following diagram:
In this example, the Identity service is is separate from the Ordering service. Obviously the Identity Microservice would need to be fetching user data from a database with things like firstname, lastname, passwords, roles/claims, etc.
Obviously other parts of the system have relations with the user. For example, every order is probably tied to the user who placed that order. In a traditional SQL database, you would simply have a foreign key to keep the relational integrity. With the above diagram the "Ordering Microservice" looks completely independent from the user database. How is relational integrity maintained in such an architecture? Does the ordering service just insert an "Order" record with the user's ID without maintaining any relationship anywhere? What happens if that user is then deleted from the system. In this particular example you would probably still want to maintain the order data, but there are lots of examples where you would want to delete data related to that user when the user is deleted. In a microservice architecture it seems like this all has to be done manually with a lot of room for error.
Best Answer
Yup
The thing to bear in mind here is that these services, even though they are called 'micro' tend to be pretty big. You will have plenty of tightly coupled objects, such as addresses or whatever within them.
Any system chooses a scope where it says "ok, I don't really care about the customers family tree going back 100 years or what type of car they drive".
Microservice architecture challenges you to consider that your total system might not be a single scope.
When you are used to programming monoliths or large relational database then the immediate thought is "but i need referential integrity between customers and orders!!" But often the realtity is that you don't.
You can imagine a whole tonne of logic related just to maintaining a customer/auth system which really has no bearing on whether your system is an ecommerce site or a message board or a tax system or whatever.
You want to be able to add features to that part of the system without concerning yourself at all about purchasing goods or filling in tax returns.
So the loose coupling of a user id in the other systems is fine, although of course you will want to be careful about senarios where user info is deleted or lost. Maintaining an audit trail or copying key fields, eg name and address across to other systems where it would be sensible to do so, say on completed order which needs a delivery label.