И сама идея, с которой пришёл автор имеет кучу проблем
1) Во-первых он взял паттерн для распределённых транзакций и пользуется им, имея а) все действия в одном приложении, б) доступ к транзакционной бд. И да, какое-то подобие саг иногда удобно иметь внутри одного процесса, но максимум ради удобного dsl, а так, и без него можно выполнение трёх функций подряд написать, никто не умрёт
2) Во-вторых, несмотря на то, что акторы снимают какое-то кол-во проблем и типа локально для себя транзакционны, получить настоящую транзакцию овер нескольких акторов нереально без третьего арбитра специально под конкретный кейс(см. кейсы для которых нужен STM)
3) В-третьих не совсем идеалогически, но навязываемо рантаймами, подразумевается, что акторы о местоположении друг друга ничего не знают, и сервис дискавери между ними налажен. Грубо говоря, если я захочу вынести группу акторов на другую машину и ничего не сломается, то я задизайнил хорошо. В этом случае придётся в сообщении пинать транзакционный контекст, здесь гайки.
ну то есть ради упражнения хорошая задачка поковыряться, но если это прод, то лучше переосмыслить