Real companion fault tolerant architecture ?

[Marc3001]

Hi,

We are actually working on implementing uppy on our photo upload system.
All is quite smooth except on the companion side.
We need companion to push files on S3 and to upload from customers social media platforms.

We just discovered from #1845 that the customers will have to stay sticked to the companion instance which delivers first response to be able to login through social media because companion instances are not sharing sessions and tokens.

As we are actually running quite fault tolerant infrastructure and want to keep quality service for our customers, we want to ensure all requests sent by our customers will be able to be handled by multiple instances of companion which do not seem to be the case for now.

I configured companion to our redis instance believing this will enable session sharing and so token sharing between instances but I was not able to see any difference in companion behaviour.

So I'm wondering what kind of architecture you are actually running on the demo instance or on the paid plan ? Do you stick customers on only one server on these infrastructure ?
Do I miss something here ?

[kvz]

This is a question that belongs more on the community forum or paid support, but yes, we use a form of sticky sessions for this. Sharing all state comes with its own set of high availability trade-offs so for our implementation where companion runs on a less-ephemeral/volatile fleet of servers, it makes sense.

If you have more questions about self-hosted companion, please refer to the support options on https://uppy.io/support/