Database-per-service pattern - AWS Prescriptive Guidance

Database-per-service pattern

Loose coupling is the core characteristic of a microservices architecture, because each individual microservice can independently store and retrieve information from its own data store. By deploying the database-per-service pattern, you choose the most appropriate data stores (for example, relational or non-relational databases) for your application and business requirements. This means that microservices don't share a data layer, changes to a microservice's individual database do not impact other microservices, individual data stores cannot be directly accessed by other microservices, and persistent data is accessed only by APIs. Decoupling data stores also improves the resiliency of your overall application, and ensures that a single database can't be a single point of failure.

In the following illustration, different AWS databases are used by the “Sales,” “Customer,” and “Compliance” microservices. These microservices are deployed as AWS Lambda functions and accessed through an Amazon API Gateway API. AWS Identity and Access Management (IAM) policies ensure that data is kept private and not shared among the microservices. Each microservice uses a database type that meets its individual requirements; for example, "Sales" uses Amazon Aurora, "Customer" uses Amazon DynamoDB, and "Compliance" uses Amazon Relational Database Service (Amazon RDS) for SQL Server.

Database-per-service pattern diagram

You should consider using this pattern if:

  • Loose coupling is required between your microservices.

  • Microservices have different compliance or security requirements for their databases.

  • More granular control of scaling is required.

There are the following disadvantages to using the database-per-service pattern:

  • It might be challenging to implement complex transactions and queries that span multiple microservices or data stores.

  • You have to manage multiple relational and non-relational databases.

  • Your data stores must meet two of the CAP theorem requirements: consistency, availability, or partition tolerance.

Note

If you use the database-per-service pattern, you must deploy the API composition pattern or the CQRS pattern to implement queries that span multiple microservices.