CODEWITHSUNDEEP
microservicesbackenddistributed-systemsystem-design
Baala Srinivas K
Baala Srinivas K

Reputation: 389

Effectively sorting when your data is distributed across different microservices

In a microservices environment, how do we effectively sort data which is part of two different microservices.

For example, lets say we have two microservices

  1. Users Service (Has all information related to users)
  2. Orders Service (Has all information related to orders placed by the user with user id as reference)

Now on Admin UI lets say we have a page where we are displaying orders placed between specific period of time and I need a sorting feature on user display name.

My question is how to achieve this effectively, below are two possible options which can be applied

  1. Fetch all data from both services and then do an in-memory merge (not efficient)
  2. Duplicate the data on the other service like adding User Display Name on Orders Service (then we have redundant data and we need to take care of consistency).

Is there any other way to achieve this, would like to know how a situation like this is solved in real world applications

Note: The scenario provided over here is more like hypothetical just want to understand how to solve when things are like this

Upvotes: 2

Views: 441

Answers (2)

Guru Stron
Guru Stron

Reputation: 143098

then we have redundant data and we need to take care of consistency

The thing is that data is not actually redundant here. Duplication of data is a very common approach in microservice architecture - specifically for the reason of performance. The main rule of thumb is that only one service should be the owner of data and others store the copy but do not manage it directly (and ideally asynchronously maintain its consistency by using some kind message queue/service bus following the eventual consistent approach).

What (micro)service will maintain the replica is up for you to decide. It can be even a separate service like AdminOrderSearchService or OrderSearchService which will use something like Elastic to actually perform search. If you don't anticipate major changes in the order search logic in this particular case I would consider to store the replica of the needed user data in the order service (it maybe quite useful in other use-cases too, so you will not need extra queries between the services).

Highly recommend to check out:

Upvotes: 1

Christophe Quintard
Christophe Quintard

Reputation: 2743

The way I solve this problem is by implementing a "order+user" microservice which is a materialized view of the "order" and "user" microservices. That means the view stores all the order with the associated user into its own table. The view listens for changes (dotted lines in the diagram) into the other microservices to keep itself up-to-date (you never directly modify the content of a view).

enter image description here

It implies a duplication of data, and it's not the simplest thing to implement, but it has the following advantages :

  • You do not make a JOIN between the database of the "order" and "user" microservices, which would lead to a database monolith.
  • You keep the "order" service clean. Imagine you want to search orders by information from the user, the products, ... That would lead to an incredible messy "order" service.
  • You will have a super fast search, because the view has denormalized the data !

Upvotes: 2

Related Questions