Everything_is_not_so_bad

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

Добавлено

Получив его ...

имеется в виду, веб-приложением.

От движка требуется способность переключаться между сеансами контекстов.

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

Работать с набором JSON файлов не практично. Стоит работать с СУБД.
Воообще, с начала стоит упорядочить все справочники, поработав над нормализацией данных. Нужно избавляться от неструктурированных данных, насколько это возможно.

Следом пришла мысль завести базу на SQLite со всеми нормами, и уже ее разворачивать при запуске приложения.

А это уже хороший выбор. Советую начать с неё.
Для поддержки JSON: https://sqlite.org/json1.html

Какой наилучший вариант для хранения справочника и быстрого парсинга оного для подгрузки в приложение?

Все справочники подгружать сразу при инициализации программы не нужно. Некоторые особо критичные данные можно подгрузить в начале, но только если они не занимают сотню МБ в памяти.

MongoDB точно не нужно выбирать на начальном этапе. Если на каком-то этапе будут чувствоваться ограничения SQLite, то стоит обратить внимание на Postgres.

Я не до конца понимаю как сделать возможность создавать ряды, где будут места с разными ценами за место

Начни с формального описания задачи: свойства объектов, их количество, что ими оперирует и т.д.

И как ставить что конкретное место уже куплено

Состояния: куплено/не куплено. Догадки о типе есть? Если нет, то надо взяться за задачу по-проще.
Принято, что места не сразу покупаются, а только по факту оплаты. Значит, нужно еще хранить привязку состояния места к тому, кто его бронирует.

Добавлено:
Изначально предупреждаю, что без хороших навыков в проектировании получится полная ерунда. Я сам участвовал в проекте, в котором строили залы с рядами, с гибкой системой цен, возможностью бронирования мест и покупки покупателями. Знаю, что там много сущностей и бизнес модели тоже могут быть разными в зависимости от технических возможностей и реализации.

А есть ли данные по распределению времени спустя которое пользователь приходит с момента рассылки?

Нужно учитывать также и время, наиболее оптимальное для пользователя. Вот, пришла ему рассылка в неудобное время. Что будет делать пользователь? Или проигнорирует её вообще или отложит сеанс на потом.

Для расчёта оптимального времени нужно знать среднее время сеанса пользователей и тогда, поделив кол-во пользователей на среднее кол-во возможных поочерёдных сеансов в сутки, получим скорость в кол-ве одновременных пользователей в один сеанс. Оно и является скоростью для рассылки пользователям.
Тогда нужно наладить рассылку с периодичностью согласно скорости рассылки.

И, возможно, нужно подумать также о том как решать проблему с одновременным посещением пользователей. Почему бот упирается в лимит и какой именно? Вычислительных ресурсов не хватает? Чего-то другого?

У приложения потребителя очереди должен иметься менеджер соединения с RabbitMQ. Как только соединение было установлено, запускается поток с веб-сервером и health-check. У потребителя очереди - основой поток, у веб-сервера - дочерний. Каждый работает независимо друг от друга. Для менеджера соединения с RabbitMQ может использоваться функция обратного вызова в библиотеке.
Таким образом, при вызове /health (или /health/live) всегда возвращается статус 200.
При внезапном разрыве соединения с RabbitMQ менеджер соединения приложения штатным образом пытается восстановить соединение (скажем, до N раз каждую секунду) и если облом, то выходим из приложения с ненулевым статусом (допустим, 1). Если приложение падает, то вместе с ним и health-check, что вызовет триггер по перезапуску приложения у процесса, который ведет мониторинг приложения.
Мониторинг самого RabbitMQ обычно ведется отдельными от приложения средствами. RabbitMQ может запускаться как on premises, так и в SaaS (допустим, CloudAMQP).

НО! Они все пользуются одной и той же БД, из которой "черпают" данные "общего назначения": юзеры, ассеты, события и пр.

Вот я и хочу "общую часть" вынести куда-то отдельно. И спрашиваю как это принято делать: библиотека? модуль? сервис?

Можно сделать как подключаемую библиотеку (пакет Java), вынеся всё в ядро самое необходимое. Вокруг библиотеки ядра могут быть созданы какие-то библиотеки-обвески. Репозиториев библиотек может быть несколько, для простоты. Каждая библиотека может иметь свою версию и использоваться монолитом при сборке.

Это значит, мне надо сделать 1000 репозиториев, в каждом Х методов (получение по ID, получение по значению поля, одного объекта, коллекции...). И ещё 1000*Х методов в контроллерах....

Ну зачем так? Нет смысла дробить даже на десятки, не говоря уже о тысячах.

Начните с разделения по модулям, где у каждого компонента своя зона ответственности и нет переплетений зависимостей с другими компонентами.
Нужно знать больше подробностей о предметной области и текущей архитектуре проекта, чтобы дать дополнительные советы.

Чтобы веб-сайт работал независимо от своего источника данных, нужно построить систему периодического обновления данных (скрейпинг, REST API или как угодно), занося данные в СУБД или сначала в очередь.

но не понимаю парсить надо все марки или только выбранную

все, чьи данные будут фигурировать на сайте.

Далее, имея данные у себя, можно подумать о реализации запросов для фильтров из клиента и подобрать СУБД для этих целей.

Существуют множество способов, один из которых - ZeroMQ - передача сообщений по сети и их обработка.

Представим, что на компьютере 1 пользователь выбрал картинку.

А где находится источник изображения, физически? Это общий ресурс для обоих компьютеров? По какому протоколу доступен?
Предположим, речь об изображении, получаемому по HTTP. Тогда достаточно знать лишь его URL и так можно оповестить о событии при помощи ZeroMQ. Получив ссылку, программа на 2-ом компьютере скачивает изображение и отображает в нужной области экрана.
Если нужно передавать данные с одного компьютера в режиме реального времени, то существуют технологии наподобие RDP, VNC и т.д.

Добавил:

какую БД можно использовать в моих целях

не факт, что в ней есть необходимость.

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

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

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

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

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

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

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

web или desktop

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

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

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

К примеру, СУБД Apache CouchDB (NoSQL) умеет сама автоматически реплицировать данные автоматически. RQlite вроде бы также.
Альтернативно можно при любых изменениях бота, подписавшись на изменения, отправлять событие по SQS и альтернативных протоколам, которые будет слушать другая копия программы и записывать в локальную БД.

Аватарка - это другая сущность, которая сбоку от пользователя.

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

Добавлено
Чтобы не тормозить основную СУБД приложения, создать slave replica и подключить Grafana к ней.

Схема:

App (W) -> DB master
Grafana (R) -> DB slave
   \
    (R)
   Prometheus

Добавлено
Забыл, что Prometheus сама забирает метрики с устройств, у которых есть HTTP endpoint торчащие наружу и выдающие данные по строго заданому темпу сэмплирования (скажем, раз в 5 сек). Тогда может и слейв реплика нужна разве что веб-сервисам, которые берут данные с нее.

Если ответ клиенту на его запрос выдается не сразу, а с задержкой в связи с ограничениями из-за API третьей стороны, то логично ввести систему заявок. При запросе регистрируют заявку клиента, заносят данные в СУБД, кладут в очередь и сразу выдается ответ с номером заявки и ожидаемым временем готовности. Когда обработчик очереди берет задачу с учетом задержки 5 секунд, получает ответ от API и заносит ответ в готовой для последующего чтения форме в СУБД для соответствующего номера заявки. Независимо от обработчика очереди, клиенты обращаются за получением готовых результатов. И если таковые готовы (проверка по колонке в таблице), выдается ответ. Если еще не готов, выдается следующее ожидаемое окно времени. И т.д., до лимита проверок.

Если же перед ответом дожидаться пока пройдет 5 секунд, то такая система быстро захлебнется при наплыве запросов и будут исчерпаны ресурсы. Поэтому RPC не рассматриваю как подходящий вариант работы.

Не нужно такого количества процессов. Для этого обходятся потоками одного процесса.
Чтобы обрабатывать много HTTP запросов, можно обходиться несколькими процессами (как это делает Nginx). Информацию можно обновлять в независимых от бота процессах - воркерах.