Илья Голец

Я бы тут ещё попробовал ответить на следующие вопросы:

1. Какие требования к срокам выпуска приложения?
   
2. Как часто будет меняться приложение?
   
3. Какой перечень клиентского оборудования и операционных систем? Будут ли это планшеты на iOs, например. Если только ноуты с одинаковой операционкой — то почему?
   
4. Какая интеграция с десктопом потребуется? Например, запуск в режиме киоска (без элементов операционной системы), горячие клавиши, локальная БД, интенсивные вычисления, лимиты памяти, нестандартные элементы управления (джойстики и т.п.), внешние динамики/мигалки/дисплеи, контроль активности пользователя.
   
5. Много ли экранных форм и насколько они разнообразны?
   
6. Какой опыт у разработчи(ка/ков)
   

Суть в том, что для работы с оборудованием, например, комфортнее десктоп (хотя и с веб это возможно). Для некоторых типов приложений мне, например, быстрее также использовать десктоп, потому что есть библиотеки, с которыми я могу простое готовое приложение сделать за часы (с валидацией и т.п.). С юнит-тестами в той среде, в которой с работаю (.Net) проще с десктопным кодом, чем с JS. Но веб, по понятным причинам, убирает многие границы (разные операционки, доставка приложения и т.п.). Опять же веб подразумевает серверную часть. В ряде случаев это подразумевает два языка программирования, две валидации ввода, две обработки ошибок.

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

Удачи!

На счёт «как эта область называется, и в какую сторону копать» — наиболее близкие по смыслу — это «Service oriented architecture» и «Event driven architecture». Подробно раскрывать не буду, почитайте на досуге.

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

Касательно масштабирования — не очень понятно, какую часть вы пытаетесь масштабировать. Мое предположение — скорее скрытые сервера, которые, как я понял, делают какую-то нагруженную обработку. При наличии очереди сообщений вы можете делать произвольное количество серверов, которые вынимают задачу из очереди, обрабатывают и помечают задание как выполненное. Более того, если разворачивать решение на облачной платформе (любой), можно создать метрику, которая анализирует длину этой очереди и при её росте автоматически запускает новые инстансы (сервера) в «скрытой» зоне. А при уменьшении очереди так же автоматически их тушит, чтобы не тратить деньги.

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

А если говорить о том, как делаются «промышленные» (не самопальные) системы такого рода, то тут будут следующие слои начиная от пользователя:

1. Балансировщик нагрузки
   
2. Веб-приложения (их может быть несколько, чтобы можно было, например, по одному отключать и обслуживать)
   
3. Очередь сообщений
   
4. База данных
   
5. Сервера фоновой обработки
   

Веб-приложения могут добавляться в пул по метрикам загрузки процессора и времени ответа.
Сервера фоновой обработки могут добавляться в пул по метрикам длины очереди.