Event Sourcing без акторной модели — это боль? Или норм?

Игорь_Прагматик
2026-07-23 21:29
Ну давай разберем. Я тут последние полгода вкатываю Event Sourcing на проекте с классическим REST API и PostgreSQL в качестве стора. Без всяких Akka, Orleans или прочих акторных фреймворков. И начал замечать, что на каждый чих приходится изобретать велосипед: конкурентность, ретраи, снапшоты, версионирование. Акторная модель вроде как предлагает из коробки изоляцию состояний и очереди сообщений, но ты ее не используешь — и сразу лезешь в дебри ручного управления блокировками и optimistic locking. С одной стороны, если проект небольшой и домен не требует высокой конкурентности (скажем, 100-200 событий в секунду), то на чистом SQL с upsert-ами и версиями строки можно жить припеваючи. Я даже написал прототип на Go с кастомным агрегатом — работает быстрее, чем ожидал, за счет батчевых вставок. Но как только появляется необходимость в сагах или долгоиграющих процессах, начинается ад: нужно хранить временные состояния, обрабатывать таймауты, не терять события при падении. Вторая боль — снапшоты. Без акторной модели ты не можешь просто взять и сдампить состояние агрегата в локальную память. Приходится либо делать это в том же хранилище (отдельная таблица), либо тянуть Redis. И каждый раз думаешь: а не проще ли было взять готовую CRDT-штуку? Но тогда теряется гибкость кастомной проекции. С другой стороны, акторная модель — это не серебряная пуля. Я видел проекты, где на Akka наворачивали столько слоев абстракции, что дебажить один event становилось квестом на неделю. Плюс лицензии, порог входа, оверхед на сериализацию. Для простого лога изменений это как из пушки по воробьям. Мой вывод пока такой: если у тебя домен с четкими границами агрегатов и низким RPS — можно без акторов, просто аккуратно проектируй схемы и не ленись писать миграции. Но если ты планируешь масштабироваться или у тебя сложные бизнес-процессы с распределенными транзакциями — лучше сразу закладываться на акторную модель или хотя бы на event store типа EventStoreDB. А то потом переписывать половину кода будет дороже. Кто что думает? Есть опыт выживания без акторов на продакшене? Или, может, наоборот — кто-то откатился с Akka на чистый SQL и не пожалел?

Войдите или зарегистрируйтесь, чтобы ответить.