Стоит ли использовать подобный метод балансировки?

Здравствуйте.
Хотелось бы узнать в профессионалов в проектировании архитектур высоконагруженных проектов в подобном подходе:

1. Запрос от пользователя идёт на кластер-балансировщик.
2. Кластер определяет тип запроса (например, что это поисковый запрос - на этом примере рассмотрю).
3. Кластер выбирает самый близкий географически и наименее нагруженный кластер для поисковых запросов, после чего отдаёт ему запрос и ждёт от него ответа.
4. Поисковый кластер, в свою очередь, скармливает запрос сначала кластеру для стемминга запроса (подбирает самый близкий и наименее загруженный).
5. Поисковый кластер кормит запрос самому близкому и наименее загружённому кластеру для классифицирующей нейросети.
6. Поисковый кластер кормит запрос самому близкому и наименее загруженному кластеру с мета-файлами, где выбирается N результатов и они сортируются методом обратной частоты.
7. Поисковый кластер собирает ответ и отдаёт его кластеру-балансировщику.
8. Кластер-балансировщик отдаёт ответ пользователю.

Передаётся строка небольшой длины — от 1 до 10 слов, в ответ приходит JSON-строка с указанным количеством (20-100) элементов и идентификатор последнего обработанного мета-файла (он же служит ID для записи в СУБД).

Сами сервера (участники кластеров) написаны на Python, использую сырые сокеты.

Хотелось бы узнать: пригоден ли данный способ с ориентацией на 10000+ RPS?

Так же я думаю, что играет роль бутылочного горлышка сам кластер балансировки, так ли это?