Let's say you are using either ServiceFabric or Kubernetes, and you are hosting a transaction data warehouse microservice (maybe a bad example, but suppose all it dose is a simple CQRS architecture consisting of Id of sender, receiver, date and the payment amount, writes and reads into the DB).

For the sake of the argument, if we say that this microservice needs to be replicated among different geographic locations to insure that the data will be recoverable if one database goes down.

Now the naïve approach that I'm thinking is to have an event which gets fired when the transaction is received, and the orchestrator microservice will except to receive event-processed acknowledgment within specific timeframe. But the question stays that what about the database ? what will happen when we will scale out the microservices and a new microservice instances will be raise up? they will write to the same database, no ?

One of solutions can be to put the database within the docker, and let it be owned by each replica, is this a good solution?

Please share your thoughts and best practices.

CodePudding user response：

what will happen when we will scale out the microservices and a new microservice instances will be raise up? they will write to the same database?

Yes, the instances of your service, all share the same logical database. To achieve high availability, you typically run a distributed database cluster, but it appears as a single database system for your service.

One of solutions can be to put the database within the docker, and let it be owned by each replica, is this a good solution?

No, you typically want that all your instances of your service see the same consistent data. E.g. a read-request sent to two different instances of your service, should respond with the same data.

If the database becomes your bottleneck, then you can mitigate that by implementing caching or shard your data, or serve read-requests from specific read-instances.