в логе только айдихи измененных (добавленных, удаленных) сущностей.
что мне ПОКА не нравится - надо делать тригер надо делать новую таблицу надо делать кодинг на бд (хотя это имхо больше может быть принято как конфигурация дб а не кодинг). и второе - что будет с перформансом когда пушнут апдейт на миллион записей.
-я так понимаю коммит будет только когда все изменения применятся (это и хорошо и не очень. хорошо потому что если что то упало то и 100% не будет ивента). ну формальная скалябельность - апстримит один подбирают много. видим мощности дб хватает - можем сделать подобие кафковых партиций в бд и апстримить через в принципе любое количество стримеров. главное чтоб база переваривала.

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

что допустимо бизнесом - ордеринг НЕ важен. если одна и та же сущность обновилась 5 раз, то мы берем только одно событие. если зависимые сущности обновились - порядок снова роли в моем случае не играет.

интеграция через базу - это один из паттернов (подходов). гибкость - понятие растяжимое. в кафку ты точно так же кидаешь (можешь кидать) джейсоны которые могут поменяться и изменение схемы будет снова геморрой.

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

что проще? поллить лог, выгребать записи, дропать все данные в ней после коммита кафки. или поллить таблицу в 200 миллионов записей и сортировать по дате?

есть третий вариант - лезем в потроха сервиса (сервисов) которые пишут-шатают базу и там втыкаем "пошли чо нить в мессадж брокер после коммита в бд". а оно возьмет и не пошлет :)

не вижу противоречий. что мешает пользовать разделенные сервисы поверх всех целых четырех основных шаблонов?
если монолит то говорить об интеграции странно ибо одно противоречит другому.
когда несколько сервисов ходят в одну базу это согласен не лучший кейс. но и не критичный. тут основнаяпролема что у тебя может быть несколько "мутаторов", и в какой то момент просто концы потеряешь. поэтому хорошо иметь прослойку между базой и чем то еще.

а так одна база на один сервис и все вроде как ясно хотя бы в этом моменте.

ну и тут хорошо бы определиться что ты вкладываешь в понятие "микросервис" а то тут могут и палкой побить если не так скажешь некоторые особо чувствительные личности :)

я тебя понял. я подумаю. в этом есть смысл. согласен.
из минусов - надо шатать легаси таблицу.
из плюсов - не надо новую таблицу и триггер.

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

мне надо написать новый сервис который работает с данными из конкретной указанной пальцем бд. и всё. то что я наворотил триггеры - это единственное что я наворотил. что мне НЕ надо - мне не надо трогать существующие сервисы. или надо но там будет дикий рефакторинг.

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