Microservice Patterns | Design Patterns | Shared Isolated Database

Microservice and Containerization Patterns > State & Data Access Patterns > Shared Isolated Database

Home > Design Patterns > Shared Isolated Database

Shared Isolated Database (Erl, Naserpour)

How can a microservice gain efficient data access to a shared database when implementing a dedicated copy of the shared database is not possible?

Problem

Sometimes, the Dedicated Microservice Database pattern cannot be applied to establish a redundant, replicated copy of a shared database. Accessing the shared database in its current environment may be unacceptable for the microservice due to infrastructure limitations and performance and reliability fluctuations resulting from concurrent usage by other consumers.

Solution

The shared database is isolated in a dedicated container and may further be encapsulated by a dedicated microservice with a generic data access API. The containerized database is independently managed and supported by the necessary infrastructure to scale with its required usage and to failover during fault conditions.

Application

Logical isolation of tables within the database may be further required to isolate datasets for specific microservices. The Leader Node Election pattern may be also applied to establish a master-less database model.

The database is deployed in its own container, allowing it to be scaled and managed independently of the microservices or any other consumer programs.

Shared Isolated Database: The shared database is deployed in its own container and encapsulated by a service API providing generic data access functions. Microservice A and Microservice B are also stored in separate containers. Now the database and both microservices can be scaled and managed independently.

The shared database is deployed in its own container and encapsulated by a service API providing generic data access functions. Microservice A and Microservice B are also stored in separate containers. Now the database and both microservices can be scaled and managed independently.

This pattern can be applied by logically isolating database tables and can further be applied in conjunction with the Leader Node Election pattern, as explained in the complete pattern description.

This pattern is covered in Module 10: Advanced Microservice Architecture & Containerization..

For more information regarding microservice and containerization courses and accreditation,
visit the Microservice Architect Certification program page..