Raul Junco@RaulJuncoV
Nobody told me I would miss my JOINs when I started in microservices.
Relational Databases are so good at joining data that we often forget how difficult it is to combine that data.
Breaking the database apart is one of the most complex tasks.
Since all those JOINs will become inter-communication calls, adding a performance tax.
In this example, we have:
- Products Catalog Microservice
- Orders Microservice
- Bestseller Report
Before the split, we had a single shared database.
Running the “Bestseller Report” was easy. I have access to the Products table, and with a single JOIN, I have the Product fields we need.
After the split, I still need the same report, but now the products table belongs to a different database.
To print the report, we need to search the Orders and call the Products Catalog for each unique product to get its information.
We've gone from our handy JOIN to an HTTP call, and the latency has grown exponentially.
We can even optimize it and make that call in bulk rather than per product, but it could still be slow.
An approach that could work:
One approach to mitigate the drawbacks of distributed data management is data replication.
The idea is to duplicate data across many services where it's needed. But it comes with its own set of challenges:
Pros:
- Reduces the need for inter-service communication, thus decreasing latency.
- It improves availability, as services can access replicated data locally even if other services are down.
Cons:
- Data consistency becomes a challenge. Ensuring all copies of the data are synchronized without significant overhead is complex.
- Duplicated data increases storage requirements.
System Design is about trade-offs, in this case, Performance and Availability vs. Data Consistency and Storage.
What would you do differently?
