Database per Service

A microservices architecture's key feature is loose coupling because each microservice can independently store data in and retrieve it from its own data store. By using the database-per-service paradigm, you can select the data stores (such as relational or non-relational databases) that are best suited for your application and business needs. This means that individual data stores cannot be directly accessed by other microservices, permanent data is only accessible through APIs, and changes to one microservice's database do not affect other microservices. Decoupling data stores makes your application's overall resilience better and prevents a single database from acting as a single point of failure.

Loose coupling is the highlight of micro service based architecture, in this situation the bare minimum criteria should be followed -

1. Independency to build, test, deploy and scale
2. Autonomous to take own decisions - Database decision plays a key role here.

Enough of theory here, let's look a hashtag#Typical Social media system design service by service, cool ......

1. Chat Service

2. Analytics Service

3. Auth Service

4. Profile Service

5. Content Service

Note:- Separation of concerns is the most important thing here and this should be keep in mind always.

Let's look at the Advantages of going for database per Service Pattern.

1. We need to have loosely coupled components- NO DIRET ACCESS OF DATABASE.

You have a very specific database need for your service, consider - Graph database to model relation in social media 2. We want granular control and scaling of our service, like-

• Horizontal
• Vertical
• Replica
• Partition
• & decentralised

In the all above situations, if a database goes down, it only affects the dependent service- ideal behaviour .

Suppose we are building Linkedin and we want to see two mersion hashtag#Amit and Amrita in the order of connection like they both are 1st order or 2nd order likewise.

This could be designed on Graph database (this is just my guess) and for this reason we can take advantage of -

1. Neo4j
2. DB graph
3. Amazon Neptune

On high level we can design like below

Let's talk about another example to power a tech Search Engine. We might need Elastic Search, because this is meant for this reason, then why do we need to build on RDBMS with writing %LIKE% query.

For specific service or business use case, we could be use use as light as possible & as autonomous as possible.

Point to be noted in certain situation- we will have separate compliance for certain type of data. e.e. Encryption at rest for PII and Financial data.

Let's quickly talk about disadvantages as well.

1. Cross-service transactions are complex and expensive in terms of time and throughput.
2. Conveying updated across service is difficult.

Multiple Infra components to be monitored and manage.

Imagine you have database like No SQL, Graph database, SQL, document storage and Warehouse what not ...

Your SRE team has night mare to handle all these.

that's the wrap buddy now..💡