Microservices and database joins

• When performance or latency doesn't matter too much (yes, we don'talways need them) it's perfectly fine to just use simple RESTful APIsfor querying additional data you need. If you need to do multiplecalls to different microservices and return one result you can useAPI Gateway pattern.

• It's perfectly fine to have redundancy in Polyglot persistence environments. For example, you can use messaging queue for your microservices and send "update" events every time you change something. Other microservices will listen to required events and save data locally. So instead of querying you keep all required data in appropriate storage for specific microservice.

• Also, don't forget about caching :) You can use tools like Redis or Memcached to avoid querying other databases too often.

It's OK for services to have read-only replicated copies of certain reference data from other services.

Given that, when trying to refactor a monolithic database into microservices (as opposed to rewrite) I would

• create a db schema for the service
• create versioned* views** in that schema to expose data from that schema to other services
• do joins against these readonly views

This will let you independently modify table data/strucutre without breaking other applications.

Rather than use views, I might also consider using triggers to replicate data from one schema to another.

This would be incremental progress in the right direction, establishing the seams of your components, and a move to REST can be done later.

*the views can be extended. If a breaking change is required, create a v2 of the same view and remove the old version when it is no longer required.**or Table-Valued-Functions, or Sprocs.

CQRS---Command Query Aggregation Pattern is the answer to thi as per Chris Richardson. Let each microservice update its own data Model and generates the events which will update the materialized view having the required join data from earlier microservices.This MV could be any NoSql DB or Redis or elasticsearch which is query optimized. This techniques leads to Eventual consistency which is definitely not bad and avoids the real time application side joins. Hope this answers.