This post is a deeper dive on the AKF Microservice Architecture Principle “One or Zero Databases per Service”.

The Predicates

Microservice and services-oriented architectures have given rise to many new availability and scalability problems. Service disaggregation approaches (including both microservices and service orientation) are broadly intended to:

  • reduce the cyclomatic complexity and associated cognitive loads and learning curves associated with monolithic applications

  • in so doing, reduce the time to market and cost to develop new solutions

  • engender higher levels of ownership and lower levels of necessary collaboration between teams

Unfortunately for most early adopters there was not also a corresponding set of principles, patterns and anti-patterns to help guide implementation. The absence of such guidance led to a number of unfortunate problematic implementations resulting in lower than desired availability or higher than desired latency. Thankfully we at AKF noticed these patterns of failures in our clients and cataloged them as anti-patterns to avoid.

Remember that when a solution is a monolith, the interactions between functions and functionality all happen through memory and within-process, resulting in very low latency and absent unintended defects high availability. When services are employed instead of a monolith, any interactions between services now face higher probability of failures due to additional network hops and higher comparative latency due to network interactions between services.

Many companies would also perform service disaggregation (or new service development) without an eye towards how the new services world should interact with persistence tiers like databases. As the number of databases with which a service interacts grows, the probability of failure also grows given the additional moving parts. Hence the principle “One or Zero Databases Per Service”. Read on.

The case for Zero Databases Per Service:

Many ephemeral compute operations (such as AWS Lambda services) may not need a database or persistence tier to support their operations. Perhaps everything they need is kept in memory, or maybe the solution is a compute only operation that parses strings and performs translations. These same ephemeral operations could also be easily represented as permanent service implementations.

Another simple case are daemons (permanent services repeating a cycle of execution) that exist to “wake up” and perform some action such as signaling another service to do some work. As they have no need for a persistence tier, we should not force them to have one.

The Case for One Database Per Service:

Most solutions and services that we create are only valuable if they can read, write, delete and update some persistence tier such as a relational database. Disallowing a persistence tier would cripple just about any solution we could create. So one database is absolutely OK and is very often necessary.

The Case for No More than One Database Per Service:

The more moving parts involved in any request, the higher the probability of failure of that request. These moving parts include every piece of equipment, software, and fiber necessary to move a request along a request-reply chain from the end user to associated databases and back to the end user.

When a service attaches to two databases, the probability of failure roughly doubles compared to a single database. The probability of failure increases as the number of databases increase. Note that it does not matter that a given request needs just one of the databases. If service A attaches to both database D1 and D2, a failure or slowness of database D2 could result in service A backing up requests for that database until such time as it fails to serve any request – even if that request only needs database D1. The case where a request requires both databases further aggravates the issue as either may contribute to backing up requests.

Microservice Anti-Pattern - Data Fan Out

While One or Zero Databases Per Service is the principal by which you should abide, a deeper discussion of the associated anti-pattern to avoid can be found in our Database Fan Out anti-pattern.

Need help with evaluating your microservice architecture? Desire training on microservices? Want help developing principles for your organization? Contact AKF – we can help! https://akfpartners.com/contact