How to keep relationship integrity with Microservice Architecture

Question

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.

Answer 1

Does the ordering service just insert an "Order" record with the user's ID without maintaining any relationship anywhere?

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.

Answer 2

I think you should have a single entry point component (maybe, eshop webapp MVC) to your miscroservices' ecosystem ,which will play the role of an orchestrator, of course your microservices might collaborate over http, but for write operations, requests of this kind should pass through a single entry and the orchestrator must assure the order of operations for a user (through a queue and operation states),otherwise, you might face a problem when an order's write occur after a user's deletion (just an example...), this why you have to maintain the order of such operations for an identity.

You could also transform you architecture to an event-driven one,which it also could assure the order of operations.

Answer 3

You use API:s and loosely coupled microservices. In practice this means REST communication between your services. If an entity is added, deleted, edited or restored in one microservice and this affects the data in other microservices, you let the first service make a REST API request over http, authenticated perhaps with a token in the http header, and that request makes the second service update its underlying data, regardless of the structure, so that it keeps its validity.