Если тебе нужно парсить события из БД, то в случае, к пример binlog’ов от mysql есть возможность группировать изменения произошедшие в одной транзакции.

Может быть ты в курсе про дополнительные требования Романа. Но я про клауд и другое не слышал)

А в файлик локальный писать - да, это просто, что может быть проще?

деталей много
файлика наверное два делать - данные, и номер строки, с которой продолжать
файл кто-то будет ротировать, данных мало-много, или он убьет весь диск вместе с тачкой?
и так далее

а так, обычно кафку юзают модные парни, с куберами и так далее, там файл - дополнительная боль

нет, нельзя.

изменения должны применяться атомарно, а это с 2 файликами не получится.

тут можно взять ACID KV бд и использовать её в качестве хранилища

Атомарность разве достижима в данном случае? Если БД захочет откатить транзакцию, что делать?

в том, что условный ROW_INSERT(table: users, values: {bla,foo,bar}) это не UserCreated{foo, bar}

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

есть разница между WAL’ом бд и логическими логами самого приложения. Мы не хотим использовать implementation detail миксервиса как сыботия для других сервисов, ибо оно может меняться, а логические события это относительно простой протокол коммуникации

писать переводчик WAL->AppLogic неоправдано дорого, проще и безопаснее хранить бд (аггрегат) и лог отдельно

Чем тогда запись в один файл будет отличаться от записи в аппенд онли таблицу?

почему не взять тогда обычный логгер и не писать на диск

log4j2