На счёт «как эта область называется, и в какую сторону копать» — наиболее близкие по смыслу — это «Service oriented architecture» и «Event driven architecture». Подробно раскрывать не буду, почитайте на досуге.
Очереди сообщений (те самые MQ из RabbitMQ) тут как раз могут быть полезны и будут помогать с масштабированием. В идеале, чтобы избежать ненужных ожиданий, хорошо бы разрешить внешним серверам работать с очередями (как минимум, писать в них задачи на обработку).
Касательно масштабирования — не очень понятно, какую часть вы пытаетесь масштабировать. Мое предположение — скорее скрытые сервера, которые, как я понял, делают какую-то нагруженную обработку. При наличии очереди сообщений вы можете делать произвольное количество серверов, которые вынимают задачу из очереди, обрабатывают и помечают задание как выполненное. Более того, если разворачивать решение на облачной платформе (любой), можно создать метрику, которая анализирует длину этой очереди и при её росте автоматически запускает новые инстансы (сервера) в «скрытой» зоне. А при уменьшении очереди так же автоматически их тушит, чтобы не тратить деньги.
В общем и целом, вся схема выглядит не сильно ужасной, но немного смущает эта синхронизация внешней и внутренней систем через базу данных. Непременно будут таймауты, если опросы с обеих сторон будут по таймеру. Можно подумать о том, чтобы использовать какие-то уведомления от базы данных, например,
в MSSQL такое есть.
А если говорить о том, как делаются «промышленные» (не самопальные) системы такого рода, то тут будут следующие слои начиная от пользователя:
- Балансировщик нагрузки
- Веб-приложения (их может быть несколько, чтобы можно было, например, по одному отключать и обслуживать)
- Очередь сообщений
- База данных
- Сервера фоновой обработки
Веб-приложения могут добавляться в пул по метрикам загрузки процессора и времени ответа.
Сервера фоновой обработки могут добавляться в пул по метрикам длины очереди.
