CODEWITHSUNDEEP
microservices
user2693928
user2693928

Reputation:

Microservices "JOINS"

Let's say we want to create the app with microservices.

We have some page where we display some items (products).

These products have multiple joins(categories, tags, users, and so on).

If users, categories data are within another services, how can we manage and filter the results?

For example in SQL you create 3,4 joins and get.

With microservices - I have to filter the categories, then filter tags and then products - this could be 10 time slower than the speed of the SQL query.

Also if I have table "products_categories" which set categories for each product which service is responsible for that? Product service or Category service ?

Thank you

Upvotes: 4

Views: 1494

Answers (4)

AjayLohani
AjayLohani

Reputation: 952

In Microservices architecture there are two ways to deal with it.

  1. The API composition pattern— This is the simplest approach and should be used whenever possible. It works by making clients of the services that own the data responsible for invoking the services and combining the results.

  2. The Command query responsibility segregation (CQRS) pattern— This is more powerful than the API composition pattern, but it’s also more complex. It maintains one or more view databases whose sole purpose is to support queries.

I will prefer to use CQRS, Define a view database, which is a read-only replica to support specifically that query. The rest of the services keeps the replica up to date by subscribing to (create, update, insert)events published by the data owner services.

Upvotes: 3

steadweb
steadweb

Reputation: 16551

What's stopping you from having multiple services for reading / writing to the same database / table? For example:

  • One service to write to categories
  • One service to write to tags
  • One service to write to products

You could then write another service to read from all three of these services, however, this might not be at a HTTP level, instead you could read from the same database within your read service and leverage the power of SQL.

The service that reads could encompass your join logic which would mean you wouldn't need to consume the other services around it.

Upvotes: 0

Robert Bräutigam
Robert Bräutigam

Reputation: 7744

I assume you created a "microservice" per database table. Those are not microservices, those are just HTTP-based CRUD interfaces to your database.

First, know why you need microservices. (Is there an actual reason?) Second, you have to create microservices that encompass at least one full (business) functionality for your software. Meaning it doesn't need other services to do it.

If you need a table that needs data from multiple microservices, you by definition made wrong microservices. If a microservice can't provide it's own UI without the help of other services, it doesn't fully contain it's own functionality.

Upvotes: 0

Deepak Singhal
Deepak Singhal

Reputation: 10864

This is a very standard problem whenever any micro-service is built.. People just always feel micro-service is the solution for everything which is not true.

Solution to this problem is designing better. Designing so that there is a balance between performance and redundancy of data. Higher performance ( lower latency numbers ) means more duplicacy of data across different databases of microservice. You should not target to achieve performance as good as SQL Joins ; but also do not duplicate data too much. A balance is needed..

Most importantly, dividing the requirement into right set of micro-services is needed.

Upvotes: 1

Related Questions