А смысл в том, что когда у толстого приложения пик, оно съедает свои
бекенды и залезает на дополнительные, у тощих приложений критичность
низкая, им можно и лагать иногда, толстое же - флагман, оно должно
всегда быть на высоте.
Так и отдайте ему все бекенды, пусть оно там живет. Если проблема в том,
что бекендов не хватает на пики обоих приложений и нужно приотеризацию
сделать, то тогда это не подходит, но и проверка бекенда GET-ом у
железного балансировщика тоже это не решит. Тут можно разве что лимитом
коннектов поиграться, но скорее все же тут нужен умный бекенд, который
будет принимать соединения на тяжелое приложение с приоритетом.
Кроме всего прочего, способ проверки живости
бекенда путем GET'а определенного URL имеет и другую полезную
особенность - можно проверить живость и отклик не только веб-бекенда, а
целиком системы appserver+dbserver, дёрнув нужный URI.
Ну для этого есть системы мониторинга, которые должны проверять эти и
другие вещи и что-то делать - от пометки бекенда мертввым то его ребута.
