Юрий Ярош

1 - гораздо короче цикл разработки, хорошо проработан инструментарий и конкретные подходы к разработке, по сравнению с JVM языками и Rust / Python
2 - надо уметь в кодогенерацию, очень много кодогенерации... потому вопросы все решаются "шаблонно" и зависят от количества уже существующих наработок и качества выработки подходов к разработке
3 - быстрое TDD, относительно большое количество стабильных библиотек аналогов которых нет в других языках, есть подходы типа zero-alloc (0lloc) и gc-less конкретно для highload'a (стоит глянуть как работает fasthttp и как там происходит аллокация, на пулах и с ресайзом слайсов), в случае с JVM надо там во всякие disruptor'ы уметь и прочий морально устаревший бред... jmh не умеет нормально полить аллокации и мониторинг GC тоже местами поверхностный, а объектная модель незаурядно раздута (привет Project Panama).
С недостатков - монолитный и топорный Runtime, а 99% поделок сообщества и правок просто обесцениваются и игнорируются... тяжко, например, там какой-нить F-Stack прикрутить и т.д. без допилки компилятора и рантайма. Хотя в случае с JVM это почти невозможно. Про Python/Rust не могу сказать.

yii1 морально устарел
yii2 дружит с PHP5.4 и вот только-только допиливается поддержка PHP7
В phalcon'e 2.1 уже есть рудиментарная поддержка РНР7, осталось только подаждать месяц-второй пока допишут.
В Symfony3 (тадам уже 3!) есть полная поддержка РНР7 ещё с предыдущего года.

Если начинать переписывать что-то на что-то РНРшное - нужно понимать что сейчас допилят РНР7 решения и всё автоматом устареет, или же отвалится из-за отсутствия обратной совместимости.

Желательно брать сразу симфонию и Sonata-Project бандлы - это будет идеальной заменой тому же WP.

Даже в случае с PostgreSQL'ем, СУБД имеют достаточно уровней инкапсуляции позволяющих разделять несколько табличных пространств и схем в рамках одной и той же базы данных.

Можно разделить все по каталогам, соответствующим базам данных, схемам и табличным пространствам - нет смысла хранить всё в одной базе, так же как и нет смысла заморачиваться с вездесущими табличными префиксами времён MySQL 3.

Зависит от конкретной версии PostgreSQL'я.
Если самый простейший - можно с коробки в 9.5 через postgres_fdw вот так . В <9.5 нельзя так как там внешние таблички (foreign tables) не могут наследоваться. Cам fdw afaik однопоточный по историческим причинам, по этому имеет смысл хранить сразу несколько шардов в пределе одного сервера.

Если нужна поддержка, и что-то попроще чем ванильный SQL, то лучше взять какое-то готовое расширение (extension) типа pg_shard, и потом докупить у них же их плюшки к PostgreSQL'ю по потребности. pg_shard умеет только операции равности (equality) хешей столбцов у шардов, эт значит что если выползти за границы таблички любым range query - оно начнёт бороздить все шарды, что порядком надоедает. Реализацию операций сравнения (больше/меньше) хешей пока не замечал, хотя давно его не ковырял. Т.е. хоть это и довольно таки простое решение, без понимания его ограничений чуть более чем наверняка можно напороться на квазилион граблей. Иногда складывается впечатление что разработчики специально затягивают feature list для того что бы клиенты переходили на их платный CitusDB.

Уууу.... CitusDB сегодня заопенсорсили.

PostgreSQL-XC нынче чуток морально устарел, и на его основе был разработан PostgreSQL-XL, про который уже упоминалось на хабре. Поддержки как таковой у него нет, но есть пару российских вендоров которые в нём перманентно ковыряются, так как это сугубо опенсорсятинка. Имхо, по функционалу оно на много превосходит pg_shard, и с ним нет таких дурацких проблем, хоть и разворачивается в разы сложнее, не без полуночного красноглазия.

Высоконагруз начинается c 50К rps и 1GBit живого http трафика без статики.
Заканчивается где-то на 10M rps и 40GBit трафика. На одну ноду.

А вот выступления на HL++ в стиле: "Мы взяли, смасштабировали наше РНР 14K rps/node на 32 машины, 20 из которых простаивают на 50%", вызывает у меня ухмылку. Наверное, по этому и не развит, что у людей как-то профилирование и вертикальное масштабирование (эффективная утилизация аппаратных мощностей) в мозгу не приелось.

Вопрос сложный не только с точки зрения реализации, но и с точки зрения отсутствия вменяемых инструментариев. Пишите OpenSource проекты, публикуйте статьи, проводите бэнчмарки - народ подтянется если оно того действительно стоит.

По поводу вариантов:
1. Гос. закупки сулят бумажными проблемами и сертификацией.
2. У "стартаперов" нет в мозгу должного QA и понимания долгосрочных перспектив, особенностей поддержки. Конкурсы и подобное обычно создаются с целью "вот мы вам дадим N рублей с расчётом, что через 5 лет вы сможете нам вернуть N * 10 рублей"
3. Читаем пункт 2.

Проекты на node.js/golang в 14K RPS и 1GBit, с фронтендами на React/Meteor, сложными или высоконагруженными называть не стоит, они сейчас скорее "стандартные" и "обоюдные".

Когда люди называют 1Гбит динамического http трафика highload'ом - это вызывает у меня довольно нелепую ухмылку.

Сравнивать php / python / ruby более-менее целесообразно так как это полностью интерпретируемые языки с кэшированием байткода, иногда с оптимизациями, как в случае с jRuby и Project Graal. Обычно такие вещи помирают на 14-17К запросов в секунду с пустыми ответами... В общем на одном гигабите трафика тут обычно всё и заканчивается. Node.js по производительности более корректно сравнивать с JVM языками типа Groovy или Scala, но никак не с самой Java. На практике через Netty на Disruptor'е под offheap'ом и Terracotta можно пропустить и 40Гбит живого трафика, без статики, - главное правильно профилировать и писать прямо pfRing.

Почти в каждом случае где есть сборка мусора нужно использовать offheap кэширование, или любые другие методы контроля роста кучи. Во время самой сборки в очень больших (16Гб и более) старых поколениях возникают проблемы с планировщиками и контролем приоритетов - в итоге получаем очень большое, критическое, увеличение текущих задержек на обработку запросов.

Если вы хотите строить что-то действительно стоящее - стоит смотреть в сторону CQRS-ES'a и реактивных приложений в рамках SOA. Возможно внедрение микросервисных архитектур если нет требований к задержкам на выполнение запросов. Но, учитывая что вы задаёте здесь вопросы о том "что лучше node.js или python" не думаю что у вас хватит опыта для построения подобных вещей.

Можно пробовать golang - яндекс слез с python'a на golang по причине слоупочности оного, и довольно хорошо так слез. В golang'е сейчас самый лучший RAD, гораздо круче того же node.js. Идеоматичность самого языка решает достаточно много потенциальных проблем ещё на этапе разработки. Да и сообщество сейчас довольно активно пилит его runtime - внедряют многопоточный gc и ещё пару вкусностей. Даже не умея всех этих асинхронностей и прочей лабуды с golang'ом можно получить довольно хороший выхлоп. Правда меня немного смущает отсутствие нормальных datamapper'ов и scaffolding'a под golang.

Можно почитать/посмотреть записи с различных конференций, посмотреть как шардят большие конторы.
1. Аутентификация != Авторизация
2. Нужно понимать что при горизонтальном масштабировании сервер не должен хранить состояний - обычно люди хранят данные сессии в просоленной куке, а не в базе.
3. Распределять нагрузку нужно в зависимости от текущей, соответственно должен производится мониторинг, и запросы должны отправляться на наименее нагруженный сервер
4. В куке сессии должен записываться IP cервера который обрабатывает запросы от текущего пользователя, а DNS в свою очередь должен отдавать адрес сервера который работает с данной сессией. Таким образом с одним пользователем может работать только один сервер, и между ними не нужно гонять никаких редиректов, но на первое время можно просто редиректить.
5. В случае с push-нотификациями, и кэшированием там вообще всё очень сложно и нужно крутить CQRS-ES, иногда нужно решать задачу консенсуса Raft'ом.