Ho do I implement Database per Service pattern in Kubernetes?

Question

Assuming I wanted to implement the Database per Service pattern or one of its related patterns like Private-Tables-, Schema- or Database-server-per-service (https://microservices.io/patterns/data/database-per-service.html) for microservices: How do I go about this if I want to run the databases in Kubernetes and not with an external database or a managed database as a service?

Do I necessarily have to use StatefulSet to deploy a database in Kubernetes, or is Deployment sufficient in some cases? If so, in which?

Assuming that a set of microservices need the ability to store, e.g., relational data in a relational database: If I wanted to implement Database-server-per-service, should every Deployment of a microservice have its own StatefulSet for its database? Or should I deploy one StatefulSet for all Deployments of any microservice and make a logical separation by creating a database per microservice in that one StatefulSet?

Answer 1

It really depends on your choice and your needs.

You should go for a single-cluster if:

• You prefer cost saving over high availability and fault tolerance
• You are short on skilled developers to manage multi-cluster

You should go for multi-cluster if:

• Your application requires a high degree of high availability, and you want zero downtime for your application. Because you don't limit your cluster with one database, you can have multiple databases in different clusters. This will allow durability for single point of failure.
• Your team has enough technical expertise to manage complex setup and maintenance of multi-cluster

With multi-cluster approach, you can configure your cluster according to your each database's needs. This will include, resource allocation, network configuration, and security configuration. For example, you can have a cluster for your production database, and another cluster for your development database. You can have a cluster for your database that requires high availability, high security, fault-tolerance, and another cluster for your database that requires low availability, low security, not fault-tolerance. You now have better control over the design and configuration of the database setup when you have more than one cluster at hand.

With single cluster, you can only configure your cluster according to your cluster's needs not your each database's specific needs.

But, don't make a choice based on this answer alone. You should also consider your team's technical expertise, your application's needs, and your budget. 99% of all cases, single-cluster approach will work perfectly for you, but it's not always the case.

I hope this helps.