The rise of microservices has fundamentally changed the way we approach application development. But with this new architecture comes new challenges, particularly when it comes to database management. One of the key decisions you'll face is whether to use a shared database or separate databases for each microservice. In this article, we'll dive into the shared database dilemma.
Shared Database is by far the most common form of integration that I or any of my colleagues see in the industry is database (DB) integration. In this world, if other services want information from a service, they reach into the database. And if they want to change it, they reach into the database! This is really simple when you first think about it, and is probably the fastest form of integration to start with—which probably explains its popularity.
In the figure below, it can be observed that our registration user interface (UI) creates customers by executing SQL operations directly on the database. The diagram also displays our finance application, which accesses and modifies customer data by running SQL queries on the database. Additionally, the marketing department can update customer information by querying the database.
Initially, we are granting external entities the ability to examine and connect to the internal implementation specifics. The data structures stored in the database are open to all; they are shared in their entirety with any other party that has access to the database. If I choose to modify my schema to enhance the representation of my data or facilitate the maintenance of my system, it is feasible that I may disrupt my consumers(Finance,Registation,Marketing). Essentially, the database serves as an extensive, shared application programming interface (API) that is susceptible to breaking. If I need to modify the procedures linked to, for example, how the Finance administers customers, and this necessitates a change to the database, I must be exceedingly cautious not to impair parts of the schema that are employed by other services. Such a scenario usually mandates a significant amount of regression testing.
Another withdrawn is consumers are tied to specific technology choice . Right now makes sense to store customers in a relational database so my consumers use an appropriate (potentially DB-specific) driver to talk to it . Suppose we determine in the future that a non-relational database would be a superior option for storing data. Would the customer service be able to make that determination? As a result, the consumers are closely linked to the implementation of the customer service, which contradicts our goal of concealing implementation details from consumers to allow the service greater autonomy in modifying its internal workings over time. This effectively eliminates the concept of loose coupling that we previously discussed in previous topics.
Finally , Let's take a moment to consider the behavior aspect. There will be certain rules associated with modifying a customer. Where is this set of rules located? If the consumers are directly manipulating the database, then they are responsible for owning the relevant set of rules. In this scenario, the set of rules for making changes to a customer could be spread across multiple consumers. For example, if the Finance UI, registration UI and Marketing UI all require the ability to modify customer data, then any bug fixes or changes in behavior will need to be implemented in three different places and then deployed. This creates a situation where we are no longer achieving a high degree of cohesion.
However, the integration of a database seems to compromise both of these principles. While database integration facilitates data sharing between services, it fails to address the sharing of behavior. As a result, our internal representation is exposed to consumers, making it challenging to avoid changes that may break the existing functionality, ultimately leading to a sense of fear towards any modification. Therefore, it is advisable to avoid this shared database approach at almost any expense.
Recalling our previous discussion on the fundamental tenets of effective microservices, we emphasized the importance of strong cohesion and loose coupling. However, the integration of a database seems to compromise both of these principles. While database integration facilitates data sharing between services, it fails to address the sharing of behavior. As a result, our internal representation is exposed to consumers, making it challenging to avoid changes that may break the existing functionality, ultimately leading to a sense of fear towards any modification.
Subscribe to newsletter for more :
https://architechinsider.substack.com/
Top comments (0)