Ultimate Guide to Database Per Service pattern in Microservices

[@alt_realm]

how are you making these animations, those are really cool. Can you share the tools you are using?

[@Zmey5656]

Excellent video. Do we allocate different database into the services?

[@sunilk9298]

Excellent animation and content🔥

[@bhaskarkaura4507]

Great video, what would be your deployment strategy for the database? Where would you keep the database? Would there be multiple instances of database as well for different service types such as payment, order service, and how would you horizontally scale the services and the database as well?

[@satish1012]

I think your question is to make DB physically separated or Logically separated right?
This is my view
Some microservices needs different database like Elastic Search, Vector DB etc. Then it is very clear we will provision these DBs
However, if many microservices are relying on MySQL DB, for small applications i would prefer to use separate schemas for each MS. If application is big and lot processing is needed we would got for each instance for each MS .
This way we can save costs also. This is also very very important factor with management :)

[@bhaskarkaura4507]

​@@satish1012 Hi, Thanks for answering, where would you deploy the DB? In separate K8s cluster? or coupled with the service cluster

[@satish1012]

@@bhaskarkaura4507
As an Architect, there are several key factors to consider:
Existing Licenses:
If the company has already invested in database licenses (e.g., for MySQL, PostgreSQL), it's practical to utilize an IaaS strategy. In this case, the database can be deployed on EC2 instances or within a containerized architecture like Kubernetes.
Trade-offs: While this approach leverages existing investments, it also brings additional responsibilities like managing backups, patches, disaster recovery (DR), and other maintenance tasks. This might require a dedicated team to ensure smooth operations.
Cloud-Managed Services:
In an ideal scenario, it's often more prudent to use cloud-managed database services, such as AWS RDS MySQL, AWS RDS PostgreSQL, or similar offerings in other clouds.
These services take care of many operational tasks, such as scaling, backups, patching, and DR, which allows the engineering teams to focus on the core business logic.
Benefits: Managed services reduce the burden of infrastructure management and offer built-in reliability, security, and scalability, which helps in aligning IT with business goals more effectively.
Cost-Saving Strategy for Test/Dev Environments:
In non-production environments (like test and dev), where uptime, high availability, and performance aren’t as critical, deploying databases within a Kubernetes cluster can significantly reduce costs. This approach avoids the need for separate cloud-managed services for each environment while still providing the flexibility and scalability Kubernetes offers.
Benefits:
Cost Efficiency: Running databases in Kubernetes helps save costs, especially for environments where database performance and durability aren’t mission-critical. You're leveraging existing Kubernetes infrastructure without the overhead of cloud-managed services.
Consistency: It also ensures a consistent environment for developers, as the same configuration and stack can be used in both dev/test environments, streamlining the development and testing processes.
Flexibility: For testing new features or conducting experiments, Kubernetes-based databases offer flexibility in provisioning, scaling, and cleanup, making them ideal for iterative development cycles.
Thanks
Sorry for long answer :)
Satish

[@ByteMonk]

Thanks Satish for adding your perspective!
@bhaskarkaura4507
IMO Each service (e.g., Payment, Order Service) would have its own database instance, whether that’s a traditional RDBMS or NoSQL database, depending on the service's needs. For example, the Payment Service might use a highly transactional database like PostgreSQL, while the Order Service might use MongoDB for flexibility. So Yes, there would be multiple databases, but one per service. This ensures that each microservice can evolve its database schema independently. For horizontal scaling of services, you would typically run multiple instances of each microservice behind a load balancer. Kubernetes or other orchestration platforms make this seamless by automatically scaling the service pods based on demand. However, I would think twice before introducing K8s into the mix, you might like to check out my latest video on K8s :)

[@bhaskarkaura4507]

@@ByteMonk ok Thanks, i've worked on K8s before so i understood the context. Cheers

[@ferlezcano]

Excellent video! Keep it up!

[@ritikagrawal1867]

Really good content. To the point

[@satish1012]

If we create DB for each service , there is a cost implication . This is for small applications. i think separate schema within the same physical DB is good .

[@daddylubarsky3049]

100%, a separate database per service only sounds good in theory (or for a very small set of very specialized services). Some companies, incl. Amazon actually try to combine DBs behind some of their microservices (or sometimes even to combine some of their microservices) to avoid the problem.

[@satish1012]

@@daddylubarsky3049 And now they are calling a seperated pattern called "Shared DB Pattern" :)
Some times i feel micro services are the most "misused" architecture.

[@prashantkumar9050]

Excellent Amazing Video. Could you please software(s) that you used to create such animated video?

[@jay_wright_thats_right]

Unable to understand the way he speaks. The majority of people who think this is a great video are other people from India.

[@ByteMonk]

I live in US :). TH-cam transcript understands it, you might like to click the CC and the playback speed to 0.75x.