Everything_is_not_so_bad

В чём сложности? Топ - это сортировка по параметру и ограничение количества результатов.
Надо изучать основы языка запросов SQL. Без этого никак.

Если схематично, то как-то так:
User flow / UX -> wireframe -> tech. design -> API contracts (OpenAPI) -> front-end + back-end (параллельно, начиная с API mocking).

Весь цикл разработки должен происходить итеративно, с поправками. Невозможно продумать всё до мелочей.
Разработаете прототип по этой схеме и продолжаете наращивать функции, по не будет достигнут MVP.

Добавлено:
И важно понять - ТЗ обычно не бывает, ибо всё делается на ходу. ТЗ это больше про средне-крупные организации, которые могут себе позволить это, теряя в скорости и делая упор на точность и соответствие по контракту.
А с макетами уже вполне можно работать в малых командах.

Протокол - это соглашение, техническое описание/механизм того как работает передача данных.

Пример: https://www.w3.org/Protocols/HTTP/1.0/draft-ietf-h...

Реализации протоколов встречаются на разных языках программирования и это не имеет значения кроме того, что они должны реализовывать все или почти все пункты протокола.

Поддерживаю совет Владимир Куц в комментариях

Я бы для начала - попробовал бы улучшить контраст. Если нет возможности сменить цвет ролика - попробовать освещение разными лампами - возможно со светофильтрами.

Если можно сделать ультрафиолетовую подсветку краёв - будет супер. Тогда дайте задание на распознавание студенту во фрилансе и это будет сделано.

1. Как распознать объект и его позицию на картинке?

   Это слишком объёмная тема. Лучше книги по распознаванию образов почитайте. А Питон или не Питон - это дело хозяйское.
   
   
2. А почему не применить какое-нибудь механическое решение? Механика проще технологически и дешевле в обслуживании
   

Если позволительно, глубину цвета можно уменьшить в настройках соединения. По крайней мере, для RDP.

IPFS + TLS ?

В общем, создаётся пул из 4*N асинхронных обработчиков очереди productUrls, каждый из которых берет из неё задачи, shift() . Этот пул запускается для асинхронной обработки очереди.

Внутри обработчика productUrlHandler очереди productUrls по окончанию скачивания страницы, кидается в другую очередь parseUrls, из которой обработчик parseUrlHandler выполняет парсинг асинхронно, независимо от скачивания страниц с другой очереди и результат парсинга сохраняет в СУБД или куда надо.

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

Поднимать несколько процессов не стоит - достаточно настроить нужный размер пулов обработчиков очередей, 4*M и 4*N. Не нужно выставлять большой размер пула в надежде, что заработает быстрее. По началу, можно взять M=N=1 т.е. пул из 4-ёх обработчиков.

Ни библиотек, ни фреймворков не подскажу. С Puppeteer не работал, помню что некто сказал, что эта штука сильно жрёт память.

С помощью модуля RediSearch можно так.
https://redis.io/docs/stack/search/reference/query...

https://hub.docker.com/_/mysql

Furthermore, it will execute files with extensions .sh, .sql and .sql.gz that are found in /docker-entrypoint-initdb.d .

Есть много вопросов к тому что из себя будет представлять конечный программно-аппаратный комплекс и для каких условий работы он предназначен. Одно дело, когда он расположен где-то в "тепличных" условиях в офисе/дома. И совсем другое дело, когда находится в шумном и пыльном цехе, где по кнопкам и экрану будут тыкать грязными руками. Ко второму должны предъявляться совсем другого уровня требования по надежности и не только.

физически подключать свой ноут к серверу

В смысле? Пойдут в серверную и будут подключать ноут к серверу кабелем? Что за бред? Если не бред, то по какому протоколу? И этот ноутбук нужен для постоянной работы с оборудованием? Или "сервером" будет достаточно мощный ПК? ПК и ноутбук в цехе? Серьёзно?

с видеокамер на которых отображается деталь

Это видеокамеры со встроенными экранами? Или же без, а изображение должно передаваться по кабелю на сервер?

будет потоковое видео и его обработка

К потоковой обработке видео, я полагаю, есть достаточно высокие требования и к железу и к коммуникациям (ширина канала, задержки, кабели, маршрутизаторы и т.д.). Должен быть чип DSP (если встраиваемое оборудование) или достаточно мощный процессор на ПК/сервере, который потянет обработку.

web или desktop

Десктоп - настольное оборудование, web - передача данных преимущественно по HTTP. Одно другому не мешает. Наверное, речь больше про выбор клиент-серверной технологии, таких как терминал-сервера с терминал-клиентами (Citrix и др.) или же комбинированного оборудования с периферией (допустим, ПК с подключеннами экраном, веб-камерой и другими устройствами). Из-за необходимости обработки видео терминал-сервер, похоже, не подходит.

Если, скажем, брать (промышленный) вариант ПК, тогда обработка видео будет происходить на нём и по сети гонять ничего не надо. Тогда настольное приложение может состоять из модулей обработки видео, бизнес-логики и пользовательского интерфейса - всё в одном. Для настольных приложений обычно берут C# (WPF), C++ (Qt), Delphi, Java (Swing, JavaFX). Модуль обработки видео можно использовать, подключив как библиотеку (SO, DLL), реализованную на любом высокопроизводительном ЯП.

Веб-технологии пока достаточно специфичны и ограничены. У меня нет пока представления как происходит пакетная обработка видео в вебе. WASM едва только пробует войти в веб и мало распространён. Одно дело на веб-приложении крутить фильмы, а нечто другое - обрабатывать на лету и встроить в пользовательский интерфейс. Так что к настольным веб-приложениям я пока несколько скептически отношусь. Они пока не предназначены для промышленного использования.

Можно. Например, встроить интерпретор Lua. Смотри проект NLua и подобные.