fix(docs): elaborate maxRetriesPerConnection

docs/gitbook/guide/connections.md

@@ -53,7 +53,13 @@ const mySecondWorker = new Worker('mySecondWorker', async job => {}, {
 
 Note that in the third example, even though the ioredis instance is being reused, the worker will create a duplicated connection that it needs internally to make blocking connections. Consult the [ioredis](https://github.com/luin/ioredis/blob/master/API.md) documentation to learn how to properly create an instance of `IORedis`.
 
-Also note that you cannot use the same ioredis connection for both Queue and the Worker as they require different `maxRetriesPerRequest` configuration. For more details, refer to the [persistent connections](https://docs.bullmq.io/bull/patterns/persistent-connections) page.
+Also note that simple Queue instance used for managing the queue such as adding jobs, pausing, using getters, etc. usually has different requirements from the worker.
+
+For example, say that you are adding jobs to a queue as the result of a call to an HTTP endpoint - producer service. The caller of this endpoint cannot wait forever if the connection to Redis happens to be down when this call is made. Therefore the `maxRetriesPerRequest` setting should either be left at its default (which currently is 20) or set it to another value, maybe 1 so that the user gets an error quickly and can retry later.
+
+On the other hand, if you are adding jobs inside a Worker processor, this process is expected to happen in the background - consumer service. In this case you can share the same connection.
+
+For more details, refer to the [persistent connections](https://docs.bullmq.io/bull/patterns/persistent-connections) page.
 
 {% hint style="danger" %}
 When using ioredis connections, be careful not to use the "keyPrefix" option in [ioredis](https://redis.github.io/ioredis/interfaces/CommonRedisOptions.html#keyPrefix) as this option is not compatible with BullMQ, which provides its own key prefixing mechanism.