Database-per-microservice assigns each microservice its own separately managed database. Services may share a database server, but they should not share databases or use a database as an integration interface. section 4.5.4 section 4.8
Apply the pattern by:
- Encapsulating each database behind the microservice that owns its data. section 4.5.4
- Hosting separate databases on one server initially to reduce cost and operational complexity. section 12.3.6 section 12.8
- Moving a heavily loaded database to a dedicated server when its workload requires more compute, memory, or storage. section 12.3.6
- Avoiding shared databases because they create coupling, bottlenecks, fragile integrations, and limits on independent refactoring. section 4.5.4 section 12.3.6
Video-streaming application
A video-streaming microservice uses its own database while a video-storage microservice hides cloud file storage behind an API. Docker Compose can run the services and database during development. section 4.5.5 section 4.8
Figure 12.16 It’s completely okay to have separate databases running on a shared database server (this is often the simplest and cheapest way to get started).
Shows the cost-conscious starting arrangement: separate microservice databases hosted on one shared database server. section 12.3.6
Figure 12.17 As our application grows larger, we can scale it by splitting out large databases into their own independent database servers.
Shows the scaling path from a shared server toward dedicated database servers for databases whose workloads grow. section 12.3.6
