My question is in context with the Serverless Architecture (e.g. AWS Lambda) and how does one interact with the Databases in this system.

Typically in a 3 Tier architecture, we have a web service which interacts with the Database. The idea here is to ensure that one database table is owned by one component. So changes in there, does not require changes in multiple places and there is also a clear sense of ownership so scaling and security are easier to manage.

However, moving to serverless architecture, this ownership is no more clear and exposing a web service to access a database and having a Lambda use this web service does not make sense to me.

I would like to know a bit on the common patterns and practices around this.

1 Answer 1


100% agree, splitting microservices into nano lambdas doesnt make sense when many of them use the same DB

Your 3-Tier architecture doesnt really change. Your one microservice protecting its database still exists, you are just hosting each of its methods separately.

But that conceptual service which groups all the functions together still exists in design and in practice as the datalayer.

Now you want to deploy an update to a single method? What version is the conceptual service? do you need to update one of the models or a table in the DB? which methods are affected and need updating?

If you want to move to nano services, whether you host them as 'serverless' lambdas or not they have to be designed as such from the ground up. Each encapsulating its own datalayer if one is required.

However. usually in such setups you the lambdas will either not have a datalayer at all, or perhaps own a single table nosqlor sqlite db for its own internal workings

Instead they will generate and process messages on a message queue. The events being passed through the system of nanoservices each doing its small bit and generating a new message.

Eventually some might persist the data or update a record somewhere and then they will be being picked up by a larger api which can encompass all the operations required by its datalayer

But you lose that, get row, change state, save row, next process gets row... flow. all the intermediary states are ephemeral messages

  • One Lambda access one table makes sense when it's a backend process. What if Lambda is still backend process and reads from a table, but the table also needs a frontend for the user to write/update values? there are 2 points of entry to the table now.
    – AgentX
    Jan 15, 2018 at 8:26
  • not sure what you mean. I would say that makes it unsuitable for lambdas
    – Ewan
    Jan 15, 2018 at 8:35
  • Let me try to elaborate - Consider that I have a workflow that runs once some event is received. I am thinking of modelling each step of workflow as a Lambda. That way I only pay for when I run that step (consider that events are not very frequent). So Lambda make sense here. But the problem on the other hand is that now my DB Table is accessed by Lambda (Read) and a UI (write).
    – AgentX
    Jan 15, 2018 at 8:47
  • remove the requirement for the read, by adding all the required data into the request. ie make the read first, assemble all the data needed for the lamba function and send it.
    – Ewan
    Jan 15, 2018 at 10:33

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.