@dphil а если служебные (worflows) очереди держать в рэббите, например? Там и роутинг есть, можно какие-то вещи роутингом отруливать

Ну, пока рабочее решение - это сами очереди держать в fdb (она быстрая и масштабируемая).
А поток "пришло событий в очередь, обработайте кто-нибудь" - через kafka
Но это противно.

Кролик с 10mln тоже не справится. Да и некоторые очереди живут неделями (и это нормально), это кролик тоже не любит

Теоретически можно было бы и все на fdb сделать, но сложнее

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

кроме основной проблемы

Нейминга и инвалидации кэшей?

Ж))

кроме проблемы миллионов очередей

А, ага.
Интересно, а это алгоритмически сложная задача или просто никто еще не написал для нее решение.

Да я думаю, что нужно всё же идти от дизайна, то есть от потребностей, в конечном счёте.
Пока массово такой задачи не стояло. Хотя, если, допустим, создавать по одной очереди на каждое сообщение (команду/событие) агретата, то очередей, очевидно, будет много. Не миллионы, но много.
Иными словами, возникла довольно интересная ситуация.
Микросервисы  (не микросервисная архитектура) оказались фейком, но популяризировали две очень важные вещи - DDD и EDA
А нативной инфраструктуры для DDD + EDA, особенно с EventSourcing, по сути нет

Ну, для сотни тысяч очередей решение есть, kafka вполне справится.
При нагрузке до 1000 mps и Postgre справится
А вот 10mln+100K - уже сложно. А это средний проект

Фил, ты с тезисом согласен?

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

Именно

Для небольших проектов можно и кролика взять, правда.
А вот для средних - уже сложно, увы.

Абсолютно

Надо таки понимать, что "большой" - это где какой-то конкретный тип сложности создаёт "большую" неопределённость. Например "сложность в масштабировании параллельной обработки данных при количестве запросов от 10 mln в секунду".

И тут мы ещё раз наткнёмся на то, что "большой" в какой нибудь системе мониторинга или IoT и "большой" в финтехе - это вообще о разном. Прикольно было бы либо "поженить" понятия "большого/маленького", либо понимая, что на открытых площадках читают всякие "неучи" типа меня или там преподавателей институтов, ну в общем достаточно много категорий проектировщиков ИТ, говорить сразу о типе сложности и её масштабе в привязке к предметке или частной алгоритмической задаче.

Ну, это да. В финтехе и 1000 платежей в секунду - много. В IoT это смешные числа.

А то выглядит несколько некрасиво и у меня складывается впечатление некоторого снобизма. Типа: -  "Все, кто обрабатывает меньше 10к сообщений в секунду - недостойны упоминания".