tripcollor, все зависит от вашей задачи. Можно и так и так - это зависит от того есть продукты с разной размерностью одного элемента или нет. В моем случае больше вносить данных, а в вашем случае при внесении перепроверять размерность и, при необходимости, рассчитывать.
AlexMine,
1. redis, имхо, не очень. RabbitMQ или Kafka - топ. Старайтесь переходить на распределенные воркеры для обработки и будет вам счастье. Событийная модель для проектов сейчас - top notch разработки
2. если у вас ошибка в обработке то вы не можете провести повторную обработку и все, приехали
4. в любую систему надо закладывать горизонтальное масштабирование
Jhn Doe from by, поэтому файловое хранилище в высоконагруженных проектах облачное и распределенное, как, например, AWS S3 и является не файловым, а объектным
AlexMine, встает ряд вопросов:
1. почему вы используете один файл
2. почему вы не храните исходную дорожку
3. обязательно ли для обработки иметь файл физически
4. в нагруженный проектах такие операции параллелятся - как вы думали решать вопрос доступа нескольких воркеров к одному файлу?)
akdes, раз по ноде то тег Javascript тут не при чем)
Зря не хотите менять фронтенд - у вас будут дополнительная точка отказа + у вас будут проблемы со скоростью загрузки. У S3 есть transfer acceleration и он отлично работает с multipart
lavezzi1, вы оперируете пользователями, а не подключениями. Что находится в users вообще непонятно. И самое главное - слиент и сервер могут обмениваться сообщениями, а вы что пробуете там отловить?
martensit, телепаты в отпуске. Вы берете язык программирования, изучаете его, пишете скрипт, ставите на хостинг то что нужно для его выполнения. Если там все есть то ничего не ставите. Вам еще вебсервер понадобится для запуска скорее всего
