Для инвалидации кеша, мы планировали использовать следующую схему:

fastcgi_cache_valid 200 … 1s;
fastcgi_cache_use_stale error updating http_503;

По истечения 1 секунды, запрос будет идти на бекенд, на котором РНР скрипт определяет изменились данные в БД которые использовались в данном URI с момента предыдущего запроса или нет (для проверки достаточно пару запросов к мемкешу), если данные не изменились, скрипт отдаст ответ с кодом 503, для того чтобы Nginx дальше использовал кеш запроса (cache_use_stale) и так каждую секунду.

Даная схема позволяет, оперативно сбрасывать устаревший кеш и хранить кеш на длительный период если данные не изменялись, так же при падении php-fpm, Nginx будет продолжать отдавать кеш.

Но для корректной работы, РНР скрипту необходимо знать что у Nginx есть файл кеша, чтобы определить можно серверу ответить статусом 503 или нет, потому что если файла кеша нет, сервер 503 ошибку от РНР отправит браузеру а этого нам не надо.

Проблема решается если в конфиге Nginx будет добавлена переменная типа $cache_status которую я буду отправлять на бекенд через
fastcgi_param CACHE_STATUS $cache_status;

Тогда РНР скрипт сможет, точно определять возможность повторного использования кеша если данные не устарели.

Варианты значений этой переменой
$cache_status = 0 (кеша нет)
$cache_status = 1 (кеш есть)

Use keys, мне кажется довольно логичный и будет многим полезным, спасибо.

В идеале хотелось бы иметь возможность, в Nginx прозрачного реверс-прокси кеширования, я здесь тоже опишу данную схему, надеюсь это не будет воспринято за флуд :)

Схема сложней в реализации, но если разработчики Nginx посчитают возможным её реализовать, мы со своей стороны готовы сделать хороший donation.

РНР бекенд отдает ответ с хедерем ETag, это наш хеш состояния данных на момент работы скрипта, Nginx по прежнему сохраняет весь ответ в файле кеша.
Но при следующем запросы на этот URI, Nginx должен сделать запрос на бекенд с хедером $http_if_none_match, РНР скрипт сравнивает текущий ETag с тем который пришел в запросе от сервера, если они равны, скрипт отвечает статусом 304 и Nginx отдает клиенту данные из кеша, а если РНР отвечает статусом 200, значит Nginx получил новые данные и должен их сохраняет в свой кеш.

Эта схема наиболее красивая и правильная, если Nginx её реализует, думаю воспользоваться её смогут многие, не только мы и это будет большим плюсом для выбора Nginx в качестве фронтенд сервера.

В принципе есть довольно простое решения с отправкой на бекенд хедера Etag из файла кеша, вам нужно сделать заполнения переменой $upstream_http_etag, она сейчас всегда пустая даже если в файле кеша есть хедер Etag, если эта переменная будет заолнина тогда все просто
fastcgi_param CACHE_ETAG $upstream_http_etag;

И бекенд будет знать, не только про наличия кеша у Nginx но и про его состояния и сможет отдать нужный ответ, если Etag актуальный бекенд ответит например статусом 503 чтобы Nginx продолжал использовать кеш по правилу из cache_use_stal.

В общем проблема упростилась, остался вопрос, как сделать заполнения переменой $upstream_http_etag чтобы в ней было содержимое хедера Etag из файла кеша?