Я мало понял в вашем потоке сознания, если честно.
Насчет документации скажу вам, что там отражены далеко не все функции и
директивы nginx, взять хоть worker_connections. И, само собой, я ее
изучал перед тем, как задать вопрос.
Как говорил мой знакомый профессор - если вы что-то не понимаете,
прочтите это еще и еще раз - пока не поймете =)
Nginx умеет делать fallback по ошибке. Ошибкой может быть таймаут -
время ожидания соединения. Если у бекенда все процессы заняты - новое
соединение отвалится по таймауту и перейдет на следующий бекенд в
апстриме. Резервные бекенды в апстриме можно пометить как backup.
Но в общем решение кривое, ибо таймаут указывается в секундах, и ибо
соединение сначало пройдется по всем разрешенным бекендам прежде чем
уйти на резервный. Но если сделать определенные патчи, то вполне себе
живое решение, хотя и костыль жуткий. Ибо того, что вы хотите - нет.
А насчет непонимания - я правда так и не понял смысла всего этого, кроме
вашего "я так хочу, значит надо". Если общее количество серверов в сумме
способно нормально обрабатывать оба приложения при одновременных пиковых
нагрузках на обы приложения, то в чем смысл выделения отдельных
бекендов? Во многом, по-этому, как мне кажется, а также в виду
неоднозначности оценки загруженности бекенда по времени ответа - в nginx
с этим никто и не играется. Если хочется все же софтового решения, то
смотрите в сторону LVS.
