serious911

0. щас делаю проект с видеочатом, использую webrtc, ограничились только хромом
1. webrtc нормально работает только в хроме
2. на flash матерятся, но flash самая модная технология доставки видео (кроме ютуба) так что его очень не скоро выпилят
3. у webrtc есть подводные камни: без STUNT сервера никуда, бывает что связь не устанавливается если в сети NAT
4. установка связи в отдельных случаях занимает 20-30 секунд, по инфе от netscan около 10% звонков не проходят
5. нельзя шарить фрагмент экрана, только отдельное окно, а если шарить tab в хроме, то начинаются адовые тормоза
6. плывет API
7. mediastream API сырой, в хроме недавно репортил баг, очень мало документации, хотя ютуб на нем работает

короче технология сырая, чтобы нормально работала, нужны коммерческие костыли (в частности в виде flash), как раз сам подумываю о написании такого костыля: https://github.com/stiv-yakovenko/reliablertc/blob... (пока в виде прототипа)

Если речь идет действительно о большом масштабировании, то см. в сторону микросервисной архитектуры.

SQL плохо масштабируется горизонтально (добавлением серверов).

Рассмотрел бы отказ от MySQL в пользу MongoDB, например, она умеет горизонтально масштабироваться.
Рассмотрел бы отказ от БД вообще в пользу Tarantool. Если оперативной памяти хватает держать всю БД в ней, то это радикально быстрее.

Клиенты будут обновлять игровое поле/комнату/стол регулярно отправляя на сервер запросы к API (возможно Long Polling).

В наше время это не круто и по ресурсам в том числе. Я бы рассмотрел вариант websocket для новых клиентов и long polling для старых.

Проблема не столько в выборе инструментов, сколько в разработке архитектуры, способной на горизонтальное масштабирование.
Нет никакой особой сложности сделать задуманное на php/python и даже perl взаимодействие через (веб-)сокеты. Преимущество node.js разве что в асинхронной работе с хранилищами из коробки, но это не означает еще, что сразу будет быстрее.
От себя бы порекомендовал использовать не MySQL, а PostgreSQL. Надежнее и как минимум не медленнее.
БД надо сразу шардировать. Как минимум шарды под пользователе-зависимую информацию.
Скорее всего также придётся написать прокси для раскидывания юзеров по разным гейм-серверам.
В общем, по хорошему нужен хотя бы сениор с опытом боевого геймдева.

немного некропостинга, надеюсь кому-то поможет не терять время.

вместо

curl_setopt($ch, CURLOPT_POSTFIELDS, array('photo' => '@'.$SERVER['document_root'].$imggr));

надо примерно так

$cfile = curl_file_create($fullServerPathToImage,'image/jpeg',pathinfo($fullServerPathToImage)['basename']);
        $data = array('file' => $cfile);
        curl_setopt($ch, CURLOPT_POSTFIELDS, $data);

ну и возможно понадобится вот этот кусок, а то везде https теперь
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);

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