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

Узнать баланс - нельзя брать из "eventually consistent", нужна строгая consistent, в той же последовательности, что и изменения баланса.
При этом не на одном счете, а на нескольких (минимум на паре).
Иначе - увы, нарушение регуляторки (

очень интересно, а что говорит регулятор дословно?

как баланс может быть strongly consistent, если он может поменяться в следующую миллисекунду после чтения текущего значения из базы? там лучшее что можно сделать - отослать новое значение сразу после изменения в клиентское приложение

все eventually consistent модели в серьёзных системах всегда снабжаются метриками, которые показывают, насколько они eventually
обычно отставание от "реальной правды" те же <100ms, но для большинства задач и секунда не страшно

У тебя не должна теоретически быть возможность, что счет в результате выполнения операции хотя бы на ms уйдет в минус.
А так как платеж - это ситуация связи многих счетов (а не одного), то без consistency по счетам - оно получается очень сложно (
Можно (блокировки, ожидание подтверждений блокировок, потом реализация с вычисткой блокировок), но на ES это делается не очень просто. С транзакциями чуть попроще. С нормальным оркестратором бизнес-транзакций - еще проще.

Событийная модель - вообще ужас обычно

"только рожающая женщина может хоть немного понять ту боль которую испытывает разработчик отлаживая код на экторах"

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

Обычно проблема что люди пихают es там где он не нужен

Ну, акторы даже проще cqrs )
Если монорепа и один язык, то чуть проще, но все равно тяжко. Я стараюсь все через workflow сделать, но там тоже не просто...

еще не читал/смотрел толком те ресурсы что указаны на странице, но м б кто-то знает еще полезные книги/ссылки на тему? https://tlroadmap.io/self-skills/communications/personal-brand.html Я видимо дед, т к я не понимаю как пользоваться твиттером для построения бренда

и вообще не понимаю твиттер

пытался им пользоваться но народ там не фильтрует контент и вроде читаешь про ИТ а тут бац и black lives matter или фотки котиков в ленте

твиттер это больше для уже публичных людей

вот если я заведу - кому я нахрен буду нужен со своим твиттером

с инсты проще  начать уж тогда

Слабенькая статья :(

а какие оркестраторы бизнес транзакций можно без боли пользовать? tibco не предлагать )

один большой мировой банк на три буквы даже сделал собственный оркестратор на eventsourced сетях Петри (Scala/Akka, опенсорс/MIT)

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

Cadence ничего. Мы свой написали (kotlin+fdb), на 2000 step-per-second на узел БД (там все в persistance упирается всегда) с горизонтальным масштабированием. Там несложно делать-то.

Риалтайм на бизнес-процессах обычно не нужен, скорее пропускная способность.

Вообще отсутствие нормального хранилища - печалит. nvme может отдать и 100k write IOPS, но системы, которая поднимет хотя бы 20k событий в секунду на 1mln очередей на одном узле - нет.
Потому и тот же cqrs с очередью на счет - не реализовать никак (

не ужто ни одна субд не может раскрыть потенциал современных ссд?