I found a solution after some research.

UWSGI is able to help in this case with a cheaper mode.

To enable cheaper mode add the cheaper = N option to the uWSGI configuration file, where N is the minimum number of workers uWSGI can run. The cheaper value must be lower than the maximum number of configured workers (workers or processes option).

set cheaper algorithm to use, if not set default will be used

cheaper-algo = spare

minimum number of workers to keep at all times

cheaper = 2

number of workers to spawn at startup

cheaper-initial = 5

maximum number of workers that can be spawned

workers = 10

how many workers should be spawned at a time

cheaper-step = 1

This configuration will tell uWSGI to run up to 10 workers under load. If the app is idle uWSGI will stop workers but it will always leave at least 2 of them running. With cheaper-initial you can control how many workers should be spawned at startup. If your average load requires more than minimum number of workers you can have them spawned right away and then “cheaped” (killed off) if load is low enough. When the cheaper algorithm decides that it needs more workers it will spawn cheaper-step of them. This is useful if you have a high maximum number of workers – in the event of a sudden load spike it would otherwise take a lot of time to spawn enough workers one by one.

Note: Worker is notified by uWSGI before being cheaped. Worker should finish until timeout is reached (this is configured by worker-reload-mercy configuration parameter). Otherwise, uWSGI kills the worker. Killing worker in the middle of serving request can cause errors or partial responses to the client.

Refer to this link for more information: https://uwsgi-docs.readthedocs.io/en/latest/Cheaper.html