For years, analysts have underlined that the success of a microservices architecture depends on limited contexts, which clearly define underlying functional logic from application state information.
Part of encouraging this appropriate separation of responsibilities is switching from a centralized database structure to one whereby every service has its own assigned data store.
Although this method encourages service independence, loose coupling and failure isolation inside the architecture, it is vital to take trade-offs: particularly, the degree of management complexity and resource demands this style of construction may impose.
Let’s examine the advantages and drawbacks of employing a shared database for microservices against a database per service. We will then look at whether the shared database strategy offers benefit in spite of any disadvantages and when it might even be the best design option.
The per-service database-based strategy
One method seeking to offer several instances of specifically tailored capability is the database-per-service approach. Services dependably run in line with a given data schema, scale against relative throughput rates, and follow the read/write characteristics of the database; database choices can be polyglot. Every service can scale on its own; any delay or failures brought on by other services are unlikely to affect sizable areas of the system.
But offering one dedicated database for every service comes with various difficulties, particularly in large-scale corporate systems with intricate integration and communication needs. Large data runs over network boundaries will take a lot of time and effort, first of all. Particularly in cases when a team neglects to sufficiently specify limited contexts, the explosion of all these databases raises the possibility of significant, resource-draining data redundancy. Furthermore challenging to regularly maintain synchronized application states is tying many databases to a big stack of independent services.
The method of shared databases
Providing a single database from which several services can draw required resources is the most direct strategy to avoid the dangers of a database-per-service approach. For example, merging disjoint set data structures is considerably easier when one uses a shared database. Distributed transactions can securely run through the use of atomic guarantees and database primitives as long as all necessary tables live inside one database.
Shared databases do, of course, present certain hazards. All the services depending on a shared database will have to update in line with the evolving schema as shared databases change with time. Another hassle is that setting the database for one service may stop another from functioning as not all services sharing a single database will inevitably use that database in the same manner. For large-scale software systems, for example, a single shared database might not be able to meet the degrees of data volume and throughput required by every service, which would force IT to suddenly split the database.
High write volumes will also affect a shared database; compaction of segment tables may result in appreciable performance declines. This scenario reflects the typical loud neighbor issue usually connected with all kinds of shared application resources.
When should one use shared databases and microservices ?
Although its practicality may seem to be negated by the drawbacks, there are still cases in which the shared database technique is rather suited for microservices. It is a good paradigm for progressive migration away from complicated, monolithic systems first of all. Regarding implementation, most contemporary object-relational mapping and web application frameworks easily let several services utilize databases concurrently without interfering with processes.
These are some situations where microservices might keep shared databases:
Separating a monolith
Starting with dividing collections of underlying business logic into independent microservices inside a shared database helps one migrate a monolith to microservices. The tables in the shared database can be logically partitioned to clearly separate logic from data as the logic is broken out into discrete parts.
One may then introduce the database-per–service approach once those tables are correctly split. It makes sensible to let a restricted number of services share databases even as other services are assigned their own separate database since a change of this kind can last months or even years to accomplish.
Excellent consistency criteria
When the main needs of architecture center on data consistency, the shared database solution also proves useful. When an architecture calls for great data consistency while having several services, it can help to establish a shared database with database-level locking and synchronizing capability. Organizations can implement this strategy by integrating it into the corporate requirements given to development teams or by making it a need in architectural design rules.
Low volume and strong interdependent relationship
When minimal volumes of data are involved, complications with shared databases are not nearly as troublesome. Long as the shared database preserves logical table separation between logic and state information, it provides a far better substitute for the technical difficulty of running several databases. The shared database can still be a good starting point until the system achieves a critical mass even if the application or number of services will expand with time.
This is particularly relevant for low-volume systems that also require a specific degree of connection among services. Given this architecture, it seems logical to keep using a single shared database since refactoring and application redesign work will be substantially reduced.
Methods for enhancing common datasets
As said before, shared databases should be used carefully since they bring close connectivity between services. Examining whether a supposed necessity to explicitly share a database between services results from an incapacity to precisely define limited contexts is also crucial.
Still, given those limited environments are well specified, there are a few strategies teams may use to minimize the negative side effects of microservices using shared databases.
Logical table partitioning
Microservices share a database, but it is possible to set a single database such that owned by certain services, tables are separated by precisely defined, logical boundaries. Simple methods of enforcing this separation include giving particular services database-specific responsibilities and access. This can assist stop inadvertent access or unwelcome coupling between services. When several services must share a single set of data, you can also build specific communal permissions used across several services.
Solo writer, several readers
Strategic usage of hot tables—a phrase used to characterize tables shared by several services—is also feasible in support of a shared database model. Approaching this might involve allowing one service in that table ownership over all data writes and update procedures. Several services can thus keep reading data without affecting the underlying writes and updates. Sometimes update data capture events could allow one to accomplish this.
