Тут кеш ни при чем. Когда вы запускаете с одним воркером или просто дев-сервер, то запущен только один процесс. Именно его конфиг вы и апдейтите.
Когда процессов несколько, а вы выполняете апдейт только в одном, то изменение только там и остаётся. Это не кэш. У каждого процесса своя память, а ваши изменения не затрагивают код, только меняют значение переменной в одном из процессов.
Вот и весь секрет.
Ключевая ошибка вот тут у вас в понимании:
использую обновление файла конфигурации, и параметров.
Вы не трогаете файл конфигурации по факту вот тем своим кодом, что привели, но даже если бы вы в этом файле конфигурации что-то поправили и сохранили, то его нужно в каждом процессе перезагрузить. Ну сделать релоад этого модуля, например.
Вообще это не очень хорошая схема динамического обновления конфигурации.
Используйте какой-нибудь механизм pub/sub (подписок на события), чтобы отправить каждому процессу сигнал об изменении конфигурации.
Ещё можно сделать механизм обнаружения изменения конфигурации в файле, чтобы этот механизм постоянно мониторил таймштамп изменения файла и сравнивал с временем своего обновления конфигурации (в памяти). При нестыковке просто перезагружаете конфигурацию. Это будет работать в каждом процессе.
Ну или лучше погуглите готовые решения для этой задачи. Их много существует. Так будет лучше.
И да, тут надо понимать, что пока у вас простой сервер и в нем не много параметров конфигурации, можно легко контролировать каждый параметр и возможные побочные эффекты от его динамического изменения. Но в сложном проекте можно легко потерять из виду какой-то побочный эффект или неявное промежуточное состояние, когда измененный вот так вот параметр конфигурации приведёт к неконсистентности состояния всего процесса.
В таких случаях при обнаружении процессом признаков изменения конфигурации имеет смысл процессу просто самостоятельно завершиться штатно закрыв все свои соединения. Ещё хорошей идеей было бы сделать это через небольшой рандомный интервал времени, чтобы все ваши процессы делали это не одновременно.
gunicorn, кажется, должен просто запускать новые процессы взамен завершившихся, чтобы сохранить нужное их количество. Тут я не уверен, нужно смотреть. Но новые процессы будут запускаться уже с новой конфигурацией, загруженной штатно, обычным и единственным способом. За счет рандомной паузы перед самозавершением процесса вы не получите мгновенного отказа всех серверных процессов.
