Э, что значит "реалтайм"? Если ты про честный, то тут начинать надо вообще с OS и подниматься выше.
Если ты просто про быстрый отклик, то можно и без CQRS/ES, никаких проблем нет.

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

я не про военный риалтайм и не про управление реакторами
я про человеческий риалтайм, можно определить например как p99 <100ms

И fp там обычно не нужен.

А тут проблема в канале передачи. Если ты про время реакции на бэке внутри одного DC, то в чем проблемы?

Но это не риалтайм, это довольно неторопливая система.

Впрочем, обычно 100ms не делают, так как придется отказаться от контейнеров, сервис-мешей, API GW и прочих удобств, которые эти 100ms съедают. Собственно логика редко требует больше 50ms

Ток ивент сурсинг мало кому нужен а импакт от cqrs больше на моделирование предметной области

Но так соглашусь

Ну и, прямо скажем, делать CQRS пофиг на чем, любой современный язык позволяет. И скорее уж современная Java, чем Хаскель )

причём тут контейнеры, контейнеры на latency никак не влияют, для сервера это просто процесс в ОС, только изолированный по сети и файловой системе
(если на сервере линукс и в контейнере тоже он)

миллисекунды съедают локи и ожидания, а также cpu context switching, когда треды блокируются на I/O, ну и вообще I/O как таковой

а CQRS eventsourcing сферическая в вакууме сущность (aggregate root) - это граф объектов в памяти, который изменяется обработкой команд последовательно, и пишет все изменения в журнал
из коего журнала она восстанавливается при необходимости в памяти в точности на момент последнего изменения
и из этого же журнала можно сделать сколько хочешь копий для чтения, не тревожа основную сущность
критичный persistence в этом случае в 99.9% случаев работает как append only
быстрее чем вот так - сделать нельзя )

Контейнеры сами - не съедают. Ингресс - съедает.

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

Ну и для современных дисков разницы между потоковой записью в append only и записью блоками в нужные места - уже нет.

память вроде нынче дешёвая, основных денег просят за cpu и iops

а с гарантиями вроде как раз всё хорошо, aggregate root это и есть транзакционная граница, strongly consistent/source of truth

Ну-ну, дешевая...

Гарантии - это что у меня не может быть теоретически ситуации ухода счета в минус, даже в технической операции )

На системе на нескольких ДЦ, конечно )

Т.е. сделать это, конечно, можно. Но решение на CQRS будет сложнее, чем стандартная многозвенка с общей БД.

с гарантиями никаких проблем, если у тебя счёт моделируется как aggregate root - то все операции с ним делаются последовательно

операция "узнать баланс" может читаться из eventually consistent реплики, а операция "зарезервировать средства" или "списать" - это команда
после fsync записи изменения баланса в журнал можно слать положительный ответ

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

*) требует наличия шардинга который даст гарантии уникальности сущности в кластере