How microservices db are updated and sync when scale? [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed last year.

Improve this question

Scenario:

1. In Case I have MS "MS-1"
2. Orchestration detect high volume
3. Orchestration create additional node with cloned MS "MS-2"
4. "MS-2" get request and update its DB

Question :

How MS "MS-1" will be updated with the new record "MS-2" insert.

Answer 1

It seems like you are under the impression that each instance of the microservice will also have its own database server that would need to be synchronized with the database servers for other instances. This is not a common implementation.

Although you do want database isolation between microservices of different types (an integration database is often seen as an anti-pattern), that doesn't mean that you need isolation for instances of the same microservice. Instead, there are two prevailing solutions.

One solution is to have a single database server. If you have different types of databases, such as relational databases and document databases and graph databases, you would have one database server of each type. You can use the server's native partioning method (MySQL calls it "schema" - other databases may have different names) to grant access to each type of service to its own tables.

Another solution is to have a database server for each service. Every service that needs a MySQL database server would have a MySQL database server, every service that needed a Neo4J graph database server would have one of those, and so on. If multiple services used the same database engine, you would have two instances of that engine - one for each type of service that needs it.

The difference between the two options is scaling. You would need to ensure that the database servers that you stand up are sufficiently powerful enough to deal with the amount of data and concurrent requests that will be sent to them. In both cases, you may be able to leverage things like read-replicas to reduce the workload on primary databases, at additional cost.