> Sergey, я вот вообще не понял вопроса, что за

реализация messaging на actors? При чем тут это, откуда это взялось?
> В чем проблема синхронизации акторов с основной моделью?
ок постараюсь быть менее абстрактным и более конкретным, итак:
1) кто сигнализирует актору о том что платеж поменял статус ? сама бизнес логика или актор сам кверит базу ?
2) если актор кверит базу - это бизнес логика или нет?
в целом, согласен с Deniel по-поводу разности понимания что такое актор и какому уровню абстракции он принадлежит.
после диалога возникает смутное ощущение что вы запилили что-то доморощенное наподобие akka-persistence и возможно даже akka-fsm, но прошу не бить больно если это не так ( людям свойственно ошибаться )

> Да, часть взаимодействия между сервисам перевели на кафку, но это сильно усложнило логику (хоть и добавило производительности).
я так понимаю вы используете ее просто как транспорт. если не секрет, откуда получилось усложнение в логике? ( в мире к которому я привык это просто как лопата )

1) Все проще. Именно актор и меняет статус платежа. Бизнес-логика шагов прохождения платежа определена как раз в акторах. 2) Да, мы сделали собственный велосипед по реализации персистентных транзакционных акторов поверх БД. Именно что-бы не решать проблемы синхронизации состояния акторов и управляемых через них данных. Я долго думал, не взять ли akka, но пришлось отказаться ( 3) Да, как транспорт. Усложнение - из-за необходимости поддерживать работу системы даже если кафка упадет ) http - транспорт, про который сразу понятно, что с запросом не все хорошо. А вот с kafka все не так жестко и нужно это учитывать. Из-за особенностей взаимодействия с контрагентами пришлось встравивать таймауты для уточнения изменения состояния при передаче событий через messaging. Да, это чуть-чуть паранойя, но от пары простоев она спасла. Кстати, корректная работа с kafka - это не совсем просто, увы. Т.е. кажется, что поставил spring kafka adapter и вперед. А потом начинаешь смотреть на поведение при различных видах сбоев и понимаешь, что все не так просто. Для нашей предметной области хуже всего - это "неопределенное состояние" процесса и приходится бороться именно с этим.