AxisPod

Основной смысл в том, что обработка ведется на основе событийной модели. Для этого используются epoll/kqueue и подобные решения в зависимости от ОС. Далее используется не одна очередь, в этом случае без использования потоков использовалось бы только одно ядро, что неправильно (именно поэтому хорошо сливают библиотеки libuv (разрабатывается для node.js), libevent и подобные). Для того чтобы полностью использовать все ядра процессора и запускается по одному процессу на ядро. По идее можно было бы использовать и многопоточность, но в этом случае потребуется синхронизация, а она в свою очередь негативно скажется на производительности.

Лучший вариант это конечно модуль для nginx, но написание своего фильтра (в данном случае он и нужен) не будет тривиальной задачей.

Посмотрите на nginx.org/en/docs/http/ngx_http_sub_module.html и nginx.org/en/docs/http/ngx_http_addition_module.html если не хватит, то копайте в сторону nginx.org/en/docs/http/ngx_http_perl_module.html

Имхо будет совсем не быстро. Ну локально файл проверить не долго, а вот проверить на других N серверах будет уже и не быстро. И опять же узким местом может оказаться канал до балансировщика (точки входа).

Я бы посоветовал рассмотреть вариант, когда на этапе генерации html контента уже известно месторасположение картинок. Каждый сервер имеет своё поддомен, например: img1.domain.com, img2.domain.com и т.д. Здесь вы так же сможете легко накинуть dns балансировку.

Ну и соответственно, если нет готовой картинки, уже отдаёте путь до пхп скрипта.

Хранить id хранилища рядом с нужной версией картинки будет не сложно.

cgi слишком медленно, fastcgi прикручивается довольно легко средствами библиотеки fcg++. Либо забить на fcgi вообще, взять к примеру libevent или boost::asio и сделать свой сервер. Для данных библиотек есть свои готовые простые примеры. Тогда просто upstream настроить и всё. Можно еще и модуль для nginx сделать, но это уже непереносимое решение.