1

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?

  • 2
    Only if the Orders Db requires that information to do its job, and it's too expensive (from a performance perspective) to ask for it from from Users service. – Robert Harvey Apr 25 at 20:12
  • @RobertHarvey I see. I guess it would be a good idea to just maintain foreign keys but also have a secondary NoSQL db (in Orders service) as "cache" for those duplicate data. – IMB Apr 25 at 20:22
  • 1
    Perhaps. It all depends on your specific requirements. – Robert Harvey Apr 25 at 20:33
3

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?

  • I agree with your points. To answer your question: 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? It can call it on the fly but this question is mostly based on "independability" of a service in case another is down. That said, a better approach I think is to call the User service on the fly but have a separate "cache" backup (NoSQL) within the Orders service in case the User service is unavailable. – IMB Apr 25 at 20:53
  • 2
    The biggest issue I've encountered with determining what information a service 'needs', especially with regards to user information, ends up being sorting and filtering. Given a list of "Orders" displayed in a table with the User's Name, implementing sorting or filtering by user name without duplicating the data is incredibly difficult (Even with an external 'search' service of some kind). – Daniel Apr 25 at 22:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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