-2

I am currently writing an application that is going to be an adaptive quiz-like site for studying. The idea is a user is studying some topic and they are given questions on the site and enter their answers. As they enter in answers, the site's backend does some logic to compare the questions they missed with the rest of the question bank to decide what the best question to give them next.

My question is whether I should continue using the AWS Lambda backend I have been using for the rest of the site or whether I need some sort of stateful backend. My thoughts are that with a stateful backend, I could store some user session data that I can update with each question they do. With the lambda, I would have to store question in the database with each update and query the database each time because the backend holds no state.

Would these constant queries slow down my application? How much? I would like to keep my current lambda backend if it is possible but don't want to do so if it will lead me to issues later on.

Logan S
  • 11

2 Answers2

4

Would these constant queries slow down my application? How much?

I've learned the hard way over many years to measure a performance problem first before trying to solve it. Even if you measure a performance problem, you should do some minimal profiling of the application to pinpoint the part of the application that runs slow. Relational databases have spent 30+ years optimizing for what-if performance issues. In general, you shouldn't.

Introducing session data gets tricky, as Ewan mentioned in a comment — and this all depends on how session storage is implemented.

If session data is stored on a single machine or in a single container, then each container ends up with copies of the same information. Depending on load balancer configurations or how clusters of containers are configured, requests could land on random instances of your application. This defeats the purpose of loading data into a session.

You can configure shared session stores, but that just introduces another component to your system that basically acts as a shared key-value database.

My best advice is to query the database as needed. Keep your application as simple as possible. Only after measuring and pinpointing a performance problem should you think about optimizations. Even then, the problem might not be solved with caching things in a session. Performance problems should be addressed on an individual basis. There aren't many universal solutions to performance problems.

Greg Burghardt
  • 45,304
1

State doesn't need to be stored on the server side and retrieved on each request. Instead, if possible, consider storing the state in the client and providing it to the server on each request (and the server sends updated, signed state back to the client on each response).

This can only really work if the size of the state is manageable but it can be used to great effect, and ensures that you can horizontally scale the servers without worrying about having to store session state in any kind of database.

RibaldEddie
  • 3,303