At some point you'll likely want to scale the number of workers working on your queue.

Make sure you assign the correct ``consumer`` and ``group`` values in that case.

The more likely case is thateachworkershall work on the queue independently, reducing

The more likely case is thatyou want everyworkerto work on the queue independently, reducing

the time needed to process the pending messages. In that case, every single worker

must have a different ``consumer``configuration value. When working with Docker

containers one idea might be to use the ``HOSTNAME`` environment variable:

must have a different ``consumer``option value so Redis can identify the different workers.

When working with Dockercontainers one idea might be to use the ``HOSTNAME`` environment variable:

..configuration-block::

That means messages would be processed multiple times. In that case, you must have different ``group``

configurations.

..caution::

Be careful when using the ``HOSTNAME`` environment variable in orchestrated environments such as Kubernetes or

Docker Swarm. It usually contains a random unique identifier which means if you destroy a container while it was

working on a message, this message will remain in pending state forever as it is very unlikely there's ever going

to be another worker with exactly the same ``HOSTNAME`` as the one you destroyed. In other words, you have to make

sure you're using deterministic ``HOSTNAME`` values such as ``worker-1``, ``worker-2`` etc.

In case you are using Kubernetes to orchestrate your containers, consider using a ``StatefulSet`` rather than

a ``Deployment`` for example.

In Memory Transport