AWS lambda and web application with sessions and databases

Question

We are in the very initial phase of developing a new web application and want to make use of Amazon cloud platform. However, we have a choice of developing web applications using Java spring framework or any other programming language/framework. The multipage application is not stateless i.e. application need to keep track of user session for transactions once logged in. Once all the required information is captured from the user through multiple pages, transaction is committed to the database.

However, there is a possibility of we using AWS lambda services for this application. Would it be a right decision to develop a web application with the above requirements using AWS Lambda (knowing that Lambda service is sessionless)?

Answer 1

Your question is not specific to Lambda. The only case where session management is easy (e.g. can be solved by in memory or file based storage) is on a single server environment. That's probably where you're coming from.

The moment you start scaling horizontally (put more servers into the mix opposed to just putting more RAM/CPU into the server) you need a central storage for sessions (and also cache). This is the same if you choose docker, or EC2 or even metal servers behind a load balancer.

This is because you never can tell if the next request from the same user will land on the same environment. That's of course also true for lambda. There's one workaround though: that is, if you use a loadbalancer to use "sticky sessions": this would route every request of the same user to the same machine, see this AWS doc on session management. But sticky session is always suboptimal (e.g. scaling down would mean to destroy sessions) plus for lambda, sticky sessions are not possible afaik.

The real solution, as the other answers here suggest, includes central session storage via Elasticache. A quote from the above link:

In order to address scalability and to provide a shared data storage for sessions that can be accessible from any individual web server, you can abstract the HTTP sessions from the web servers themselves. A common solution to for this is to leverage an In-Memory Key/Value store such as Redis and Memcached.

Answer 2

There is a lot to consider when deciding whether a serverless architecture is a good fit for your application. I don't think there is a "one size fits all" answer to this question.

Using Lambda instead of, say, a servlet container, does indeed introduce a bit of development overhead with respect to session persistence. However, I don't think this should necessarily be a primary consideration when asking yourself if a serverless architecture is appropriate for your application. Before worrying about how session is going to work, I'd ask myself:

• Am I willing and able to write the application as a collection of microservices, accepting the additional operational and development complexities that come with that approach?
• Am I willing to use a client-side rendering approach to my UI? If not, does the server-side rendering technology I've chosen integrate easily with Lambda?
• How much business logic can I (safely) embed on the client side?
• What are my traffic patterns (and by extension, scalability needs)? Is my traffic steady? Spiky? Do I have long periods of dormancy?
• Is serverless likely to have a cost advantage over EC2?
• How detrimental will Lambda cold starts be to your UX?
• Finally, with respect to session, how sensitive is the data in session? Is a "stateless" session using JWT an option?

If your application truly is a good fit for a serverless architecture, the overhead of figuring out how to persist session probably isn't so costly as to be a deal breaker.

In my experience, developers (including myself) struggle much more with paradigm shift to microservices and (often) client side rendering, than they do with the peculiarities of how session is implemented or persisted.

Answer 3

You may have a stateful application running on Lambda if you can use an external persistent storage for your session data.

You can use DynamoDB or Elasticache for example as your temporary storage for your session data and once all the required data is ready, you can then persist them permanently in your database queries.