Having read through various microservices literature, I've seen a common recommendation that a microservice should generally be fairly cohesive, owning its own data repository, and serving as the single interface to its data repository.

But now with AWS Lambdas, I'm seeing more occurrences of multiple Lambdas reading to and writing from the same database. A shared database, including the same tables.

Is this generally an antipattern? These multiple Lambdas, which can be spread across multiple codebases, might all need to be updated at once if one Lambda needs the db schema to change.

But at the same time, Lambdas can be so granular that a collection of them can be conceptualized to be one microservice - after all, one microservice might still have multiple endpoints, when a Lambda has only one.

I suppose the best way to judge would just be to see if it's causing a problem, like if coordination costs are high. But I wonder if there are generally recognized best practices regarding Lambdas and shared databases.


1 Answer 1


Recommendations like “every service should have its own database” are just guidelines.

The point of this guideline is that if a database were to be shared between multiple services, this would obscure the real data flows and will complicate changes to the system since other services might be affected by a change. In essence, following this guideline allows us to treat the database as a trusted part of the service, and not as a separate service that our service connects to.

It can be reasonable to deviate from this guideline:

  • We might agree with this guideline, but decide not to follow it in particular circumstances because we value other aspects more.

    For example, a shared database might allow for strong consistency guarantees (like foreign-key relationships, constraints, and transactions across multiple tables) that you just can't get when splitting your data across multiple databases. This can have real value that outweighs the increased maintenance burden.

  • We might follow the guideline, but define the boundary of the service in a somewhat unusual way.

    This is what you suggest in the question: multiple Lambdas might conceptually behave as a single service.

Let me expand on this second part.

The main value of microservices in particular is that they can be developed and deployed independently1. If multiple Lambdas are owned by the same team so that they are always developed together, then there may not be any advantage from treating them as separate microservices – even though they are deployed somewhat independently.

Signs that the Lambdas are actually developed as a single service could be that their source code is part of the same repository, that libraries are shared between these Lambdas, or that development work (such as refactoring or new features) affects multiple Lambdas at the same time.

If the Lambdas are already developed together, then it is also possible to upgrade them together in order to change the database schema. Since the team can change all affected code, there doesn't have to be any breakage. The team owns all the code that accesses to the database, so there won't be unexpected changes by third parties.

So I would tend to agree that some microservice oriented guidelines are not directly applicable to a FaaS context, though their intention can be translated. Sometimes, this can mean that multiple Lambdas conceptually behave like a single service. But this doesn't mean that we can throw all previous wisdom out of the window: if two Lambdas that are developed independently share the same database, this will lead to the same pain points as when two independently developed microservices share a database.

1. This is my short definition. See “Microservices: a definition of this new architectural term” by Lewis and Fowler for a more thorough perspective.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.