lubezniy

Файл JSON-ом не передать. А способ хранения выбирается исходя из того, сколько таких вводов будет, каков предполагаемый размер файла и что дальше требуется со всем этим делать.

На бэкенде надо CORS реализовать (заголовки Access-Control-Allow-Origin в http-ответе, иногда ещё и другие). Тогда заработает.

Если ограничить нужно по всему nginx, то в http. Если по некоторым серверам, то в server. Если по каким-то путям, то в location.

Здесь важно, чтобы в память помещались индексы. Ну и настройки MySQL надо выставить так, чтобы выделяемой памяти под них хватало. Ещё неплохо бы SSD, если записи мало: с ним производительность взлетает.

php.net/manual/en/function.number-format.php

На мой взгляд, нюансы такие:

1. Вместо bindParam лучше bindValue с теми же аргументами пользовать;
2. С die на проде поаккуратнее; лучше инфу об ошибках в отдельный лог писать.
3. Хорошим тоном является после окончания всех fetch-ей на датасете вызывать closeCursor().
4. Выборку * в sql-запросе полезно заменить на конкретный необходимый в работе набор полей: при их большом количестве можно поиметь дополнительных проблем.

Не скажу за раздачу именно IPTV, просто про общие принципы работы highload-сервисов (опыт имеется). Не надо по возможности зацикливаться на одном сервере ни в какой точке. В этом раскладе достаточно упасть одному каналу - и всё. Балансировщик в принципе может отдавать пользователю только ссылки на другие серверы, не неся почти никакой нагрузки на канал. Второй балансировщик желательно поставить в качестве резервного или в качестве дополнительного (лучше в отдельном от первого датацентре), делая round robin через DNS. Ну и серверы отдачи тоже в нескольких датацентрах заказать, чтобы они цеплялись в Интернете к разным провайдерам - опять же по причинам отказоустойчивости. Ну и для приёма сигналов и раздачи потоков тоже несколько машин не помешает. Раздачу между серверами при большом их количестве можно и в несколько уровней выстроить. Но здесь ещё нужно будет отдельно и специально задумываться о мониторинге и администрировании, чтобы можно было одинаково быстро отслеживать сложности у разных датацентров-провайдеров и соответственно дёргать разных специалистов.

Их нет... их нет совсем (с).
Пока из описанного можно только утверждать, что смотреть нужно в сторону лазерников. Для выбора конкретной модели принтера нужно определиться с множеством критериев:

1. Формат бумаги (полагаю, A4);
2. Возможности печати по сети, наличие проводного или беспроводного порта;
3. Ожидаемая нагрузка на принтер в день и в месяц (точность до сотен листов в день и до тысяч в месяц);
4. Доступность и стоимость расходников в ближайших (самых ближних и чуть дальше на всякий случай) магазинах;
5. Ресурс печати до ближайшего ТО (maintenance, если по-буржуйски), стоимость ТО (комплектуха плюс работа);
6. Стоимость самого принтера конкретной модели - для определения разумности.

8 гигов на 5-10 человек -это немало. По крайней мере, потестить переход стоит.

Считаю, что фронтэндеру для взаимодействия с бэкэндом необходимо в должной степени знать используемые в обмене протоколы и стандарты (HTTP(s), JSON, XML, HTML, SOAP и т. д., и т. п.), уметь разбираться с производительностью с помощью браузерных средств отладки (на уровне - это сервер долго запросы отрабатывает, или же фронтэнд тормозит от большого количества выводимых данных). Фреймворки - ИМХО клиентские и составные (клиент-серверные).

Для подключения через NAT (не важно, абонентский или провайдерский) при отсутствии у абонента белого IP используется внешний сервер, к которому устанавливают подключение обе стороны обмена. И инфа идёт через него.
Если провайдер и так даёт белый IP (только динамический), можно воспользоваться какой-нибудь службой DDNS и пробросом портов на своём роутере.

Из телефонов с двумя портами - например, D-Link DPH-150S (брал, правда, лет 5 назад; не знаю, производятся сейчас или нет). По цене адекватно, дисплей простенький есть (без него брать не рекомендую).
Если связь только внутренняя, то без АТС не слишком удобно, но можно и вообще обойтись, сведя телефоны в одну сеть и дав им постоянные IP-адреса (либо статикой, либо настройкой на DHCP-сервере по MAC). Просто вместо номера на телефоне набирается IP-адрес и делается звонок.
При необходимости внешней связи из АТС при подключении телефонов к Интернету можно рассмотреть и виртуальные варианты; это удобно, когда нет своих городских номеров или хочется заиметь многоканальный.

Партиционирование или шардинг должны помочь. Грубо говоря, задача - сделать отдельные таблицы для разных хостов или действий и в зависимости от значения выбранного параметра для разделения добавлять запись в соответствующую таблицу. Партиционирование встроено в MySQL, но имеет свои ограничения. А шардинг делается на уровне скриптов. Плюс последнего - можно писать не только в разные таблицы, но и в разные БД даже на разных серверах (при высокой нагрузке так можно обеспечить масштабирование).

Не скажу за то, как сделано, но window.confirm в принципе использовать сейчас крайне не советую. В некоторых конфигурациях Chrome (мне так и не удалось понять, в каких) при вызове window.confirm вместо окошка вываливается JavaScript-ошибка в консоль.

Установить расширение mysql. Для php7 - скомпилить (идёт в виде pecl).
А вообще предпочтительнее использовать PDO или хотя бы mysqli. Но для них соответствующие расширения нужно установить.

Если инфа на диске не зашифрована, вряд ли будут сложности. А при шифровке можно ожидать чего угодно.

Хостер A при отказе от услуги может отказаться от DNS-поддержки домена и убрать соответствующие записи. Про последствия, думаю, сами догадаетесь. Сам в этой связи предпочитаю DNS отдельно, хостинг отдельно.