hat is the standard pattern of orchestrating microservices?
If a microservice only knows about its own domain, but there is a flow of data that requires that multiple services interact in some manner, what's the way to go about it?
Let's say we have something like this:
Invoicing Shipment And for the sake of the argument, let's say that once an an order has been shipped, the invoice should be created.
Somewhere, someone presses a button in a GUI, "I'm done, let's do this!" In a classic monolith service architecture, I'd say that there is either an ESB handling this, or the Shipment service has knowledge of the invoice service and just calls that.
But what is the way people deal with this in this brave new world of micro-services?
I do get that this could be considered highly opinion-based. but there is a concrete side to it, as micro-services are not supposed to do the above. So there has to be a "what should it by definition do instead", which is not opinion-based.
Shoot.
well there are various ways of best database practices when dealing in micro services , it may differ with respect to domain of the entities which are being used , and also the scope of your application use.
There are few best practices for database design in micor services , to start with listing few of them
1 - Private-tables-per-service – each service owns a set of tables that must only be accessed by that service
2 - Schema-per-service – each service has a database schema that’s private to that service
3 - Database-server-per-service – each service has it’s own database server.
You can mix and match these are per your data size and data count.
I would like you to refer and go through this page for a perfect example.