Shared Database Pattern in Microservices
Microservices need to communicate with each other, and one such way of doing it is through a shared database.
For example: While building a multi-user blogging application, say we have a Blogs service that manages all the blogs-related information and we have an Analytics service that takes care of all the analytics like Likes, Shares, Views, etc.
Analytics service updates the information asynchronously directly in the blog's database; eg: total_views that happened on the blog. This can be easily achieved by sharing the database between Blogs and Analytics, and this pattern is the Shared Database pattern.
Advantages of sharing the database
the simplest way of integration
no middleman involved
no latency overhead
quick development time
Challenges with Shared Database
There are 4 challenges to using this pattern
External parties know internal details
By sharing the database across services, an external party (Analytics) would get to know the internal details of the Blogs service; eg: deletion practice, schema, etc.
This leads to a very tight coupling between the services; which then restrains the maintainability and performance of the system. For example, whenever the Blogs service changes the schema, the Analytics Service would have to be informed about the change.
Sharing the database is sharing the logic
To compute some information we need to query a set of tables; and say, this information is required by the Blogs, Analytics, and Recommendation service.
The business logic to compute the information has to be replicated across all the 3 services. Any change in the logic needs to be made across all the services.
Risk of data corruption and deletion
There is a risk that one of the services might corrupt or delete some data given that the database is shared between the services.
Abusing the shared database
One service firing expensive queries on the database will affect the performance of other services sharing the same database.
When to share a database?
A shared database pattern is helpful when you are seeking quick development time. Although it is not the best practice, sharing the database does reduce the development effort by a massive margin.
Sharing the database is also seen where it is inconvenient to have a middleman for the communication; for example: sending a notification to a million followers of a person is simple when the Relationship database is shared with the notification fan-out service; instead of iterating the millions of followers through some middleman API.
Here's the video of my explaining this in-depth 👇 do check it out
Microservices need to communicate with each other. Communication between them is always about getting or updating data that is owned by the other service. What if a service gets direct access to all the data it wants? This is the simplest way for the microservices to communicate with each other, and this pattern is called Sharing the Database. The core idea here is to let anyone who needs the data from a service or wants to update something, can directly talk to its database - no middlemen needed.
Although most people think it is the wrong way of communication, we should not discard it completely. In this video, we talk about what this architecture pattern is, the 4 challenges associated with it, see ways to mitigate them, and understand when and where it could be beneficial for us to share the database rather than going through a middleman.
Outline:
00:00 Agenda
03:13 Introduction
04:14 Advantages of a sharing a database
06:55 Challenge 1: External parties getting internal details
10:30 Challenge 2: Replicating business logic
13:31 Challenge 3: Risk of data corruption and deletion
14:50 Challenge 4: Abusing the shared database
16:27 Should we share the database then?
You can also
Subscribe to the YT Channel Asli Engineering
Listen to this on the go on Spotify
Thank you so much for reading 🖖 If you found this helpful, do spread the word about it on social media; it would mean the world to me.
You can also follow me on your favourite social media LinkedIn, and Twitter.
Yours truly,
Arpit
arpitbhayani.me
Until next time, stay awesome :)