Дмитрий Свиридов

Нет, потому что 500 человек, грузящие на сервер видео для обработки, и 500 человек, просто читающие на сайте статьи - это совершенно разные вещи, которые требуют совершенно разные конфигурации сервера.

Важна производительность, поэтому и стал вопрос о переходе от PHP/Laravel

Тут вообще нет связи. Узким горлышком в таких проектах является не язык, на котором приложение написано, а база данных. Если медленно выполняются запросы, то хоть на ассемблере бэкенд напиши - быстрее сервер отвечать не будет. Ну может пару миллисекунд выиграете, но на фоне времени выполнения запроса в БД и сетевых издержек это смешные цифры - даже не заметите разницу. А если речь идёт о Django, то это вообще не про производительность, потому что этот фреймворк довольно тяжёлый сам по себе, да и Python - это далеко не самый производительный язык даже среди скриптовых.

Если речь идёт про большие нагрузки, то тоже язык тут не особо при делах, потому что обеспечиваются они масштабированием, кешированием и оптимизацией запросов к БД. Язык приложения тут вообще не при чём - разве что памяти какой-то больше жрёт, какой-то меньше. 200к в сутки - это в среднем всего лишь 2-3 запроса в секунду - то есть вообще ни о чём. Понятно, что распределение посещаемости вряд ли непрерывное равномерное, но тем не менее 200к даже если за один час - это всего лишь 140 запросов в секунду. С такой нагрузкой справится любой современный язык и фреймворк даже без масштабирования, кстати.

Загружайте файлы не в папку, а в s3-совместимое хранилище (чтобы при желании можно было без страданий и изменений в коде перейти на Amazon или в Linode какой-нибудь) - MinIO. Т.е. генерируете некий id, превращаете его в хеш, формируете ключ и по нему льёте в MinIO. Причём храните только оригиналы.

Что касается миниатюр, то их нарезать и хранить не нужно. Представьте, если размеры в дизайне поменялись - что тогда? А если для каждой миниатюры webp-версия потребовалась - все картинки опять обрабатывать? Есть решение - imgproxy. Это специальный прокси-сервис (можно на свой сервер поставить, как и MinIO), который нарезает картинки "на лету" в момент обращения (по параметрам в url). Кроме нарезки, есть ещё куча разных возможностей. Кеша внутреннего нет, т.е. перед imgproxy есть смысл поставить Nginx для кеширования миниатюр (чтобы при каждом обращении не нарезало).

Вот по этой причине я ушёл в сторону разделения фронтенда и бэкенда. Бэкенд - API, работающее с JSON, а весь фронтенд - это React/Angular/Vue приложение. Валидацию в таком случае надо делать и на фронтенде и на бэкенде, либо только на бэкенде. Конечно, с точки зрения удобства использования вариант валидации на фронтенде и на бэкенде выглядит более интересным, т.к. для валидации не требуется делать запрос на сервер. В то же время тут могут быть сложности с соответствием валидаторов на сервере и фронтенде (если это очень трудоёмко, то можно валидацию оставить только в бэкенде). Плюс такого разделения заключается в том, что вся работа с формами, стилями, виджеты и прочая интерфейсная часть с бэкендом вообще никак не пересекается. Код получается более простым для сопровождения (нет каши), кроме того легко разделяются обязанности.

Смотря как сайт реализован. По большей части используют реляционные СУБД, так что да - обычные ssl-таблицы. Но данные могут по-разному храниться. Например, в MongoDB или даже просто в обычных текстовых файлах.