Dash Scalability - Gunicorn and stateless app functionality

Dash Python
1

Hi there,

I need some assistance in understanding exactly how Dash processes requests in a multi user environment and whether there are potential risks for race conditions/collisions.

I am running a dash app on an AWS ECS task with 8 gunicorn workers. This app can be accessed by multiple users from remote locations.

Our component IDs are fairly predictable (i.e dropdown button is dropdown-button). Does the callback map on the backend distinguish between the various worker processes? For instance, would it be possible for two callbacks in remote locations to become tied to a race condition, where the value of a given output become based on a first come-first served (or equivalent). If this is the case, would it not be possible for requests to become cross-contaminated?

We don’t currently have any session based management on the app which would be an obvious solution (to perhaps a non-existant problem).

Apologies if a silly question but we’re trying to process any potential issues in scaling our operation.

Thanks

2

If I understand the question, I think the answer is that if the app is stateless the issue doesn’t really arise (and the reason for writing stateless apps is just to avoid this kind of issue).

This is discussed at this link, which also gives a range of approaches to storing modifiable data that does need to be shared between user sessions - does it answer your question?

1 Like