Опишу некоторые, особенности работы модуля PURGE nginx, с которыми я столкнулся и которые затрудняют его использование в hi-load:

Как известно, механизм purge в nginx призван для управления кэшем, единственным его предназначением является очистка кэша для необходимого урла на сайте.

Мы могли бы закэшировать страницу с урлом http:://mysite.ru/main/, к примеру, на сутки и реализовать в форме отправки сообщения нашего сайта инициацию запроса http:://mysite.ru/purge/main/, который, при должной конфигурации, очистит кэш для страницы /main/. На первый взгляд, всё выглядит идеально и придраться не к чему, но если разобраться, то не так всё гладко, когда дело касается hi-load. Дело в том, что nginx производит очистку кэша в таком порядке:

a) После выполнения PURGE запроса он удаляет закэшированную копию страницы из хранилища.
б) Ждёт сгенерированную, новую страницу от бэкэнда.
в) Отдаёт её пользователю и кладёт в кэш, далее продолжая раздавать её пользователям.

Всё шикарно, но при выполнении пункта "б" он, если к нему обращается клиент, не находя страницу у себя в кэше, пропускает все запросы к фронтэнду.

Теперь допустим сценарий, ваша страница /main/ генерируется на бэкэнде 1 секунду и он настроен таким образом, что максимальное количество клиентов на нём не должно превышать 300. Посещаемость /main/ - 600 запросов в секунду, каждый новый клиент увеличивает время отработки запроса к фронтэнду на 0.3%. Мы видим, что, количество клиентов, которые пройдут на бэкэнд, превышает в два раза разрешённый лимит, а время выполения запроса, в первые полсекунды, будет расти по экспоненте и скрипт, в лучшем случае, завершит работу через несколько секунд, а в худшем, бэкэнд вернёт 502 ошибку, из-за ограничений на время выполнения кода на фронтэнде, то есть, фактически, уронит ваш проект.

Точно такая же ситуация будет, если элемента ещё нет в кэше и на него внезапно начинают обращаться пользователи (допустим произошла публикация новой страницы).