each microservice need its own database
A separate DB per microservice is not a prerequisite (nor a requirement, really).
You can have as many microservices as you want working on top of the same database, but use different schemas for example.
The bounded context of a microservice should be the boundary.
Lets say we have very high load on this service, so we choose to scale out 20x.
Scaling to (X) instances of the same microservice does not mean necessarily having a separate database per each instance of that same service.
Most databases are designed with concurrent connections, users, transactions in mind. a single database instance (with some optimistic concurrency) can handle hundreds (if not thousands) of concurrent connections gracefully.
If you explicitly chose to have a separate DB per instance of the same service, then you will have to sync those databases up. and, most likely, data consistency will suffer for it.
Here are some suggestions:
-
use a single database per microservice (not per instance) no matter how many instances are using it. And only consider a DB per instance when you’re sure a single DB cannot handle the load.
-
Use a shared cache layer on top of the DB (maybe redis cache)
-
Use a database cluster to deal with high load/availability of databases.