Does a microservice's individual database need to have complete data?

Question

Say you have a Users and Orders service and they have their own database.

Since microservices need to stand on their own even if another service is unavailable, does the Orders DB need to have all the complete details of the user who ordered instead of the usual foreign key reference (e.g., user_id) ?

Example:

Users DB:

• user_id
• name
• email

Orders DB:

• order_id
• user_id
• user_name
• user_email

Do you need user_name and user_email duplicated in the Orders DB?

Answer 1

I'll answer your question with a question: what data about the user does your Orders microservice need?

• If the Orders service needs to know a user's email address, then it would make sense to store users' email addresses in its database.
• If the Orders service does not need to know a user's email address, then it does not make sense to store it.

Always keep in mind that duplicating data has a cost. Duplicated data has to be kept in sync with its source of truth, which creates code overhead, opportunity for bugs, as well as backup and recovery headaches (i.e. in which order must databases be restored in order to preserve consistency?)

As for foreign keys, hey, it's a distributed architecture. You're going to have to give up some foreign keys unless you switch to a monolith. Within a database, you should employ foreign key constraints for the data set you need to store, but I wouldn't store extra data just for the sake of foreign keys.

The two biggest issues with storing a copy of another service's data in your service's database for the sake of foreign keys:

• Keeping the data consistent as it changes. Challenges from past experience:
  • How to handle deletions?
  • What about when the source database is restored from a past backup?
• Slippery slope problem. If you add in users and users are dependent on customers, do you store customers? If customers are dependent on billing addresses, do you store those too? Where do you draw the line? I draw the line at the beginning by not storing anything just for the sake of a FK which is not otherwise needed.

With microservices, data duplication in general is impossible to avoid completely, but superfluous duplication is just inviting problems.

That said, if you need the data, go for it. Just make sure you build in a way to resynchronize the data and always know who the source of truth is. When possible, try to establish a one-way data flow.

Food for thought: If your Orders service needs to know details of a user, is it necessary to store it, or could it call the Users service API on the fly?