3 ms·
What do you think of avoiding implementing Outbox by just having things like Kafka Connect subscribe to the table changes in the database?
by skrtskrt 5y ago
What do you think of avoiding implementing Outbox by just having things like Kafka Connect subscribe to the table changes in the database?
- zeroc8 5y agoOne thing would be that you then are just syncing database as opposed to sending domain events, aren't you?
- skrtskrt 5y agoGood point, but you could have the sender/pusher process read from Kafka Connect and parse into a domain event before pushing. It sounds roundabout, but you're letting a battle-tested implementation handle the database-table-listening aspects with no special outbox implementation needed on the database write.
- deleted 5y ago[deleted]
- lmarcos 5y agoHow do you handle domain events that are the composition of columns of different tables?
- playing_colours 5y agoYou can use views.
- zeroc8 5y agoIn our case it's not the easy to reconstruct domain events from CDC - in many cases, multiple events are affecting the same tables.
- playing_colours 5y agoIt can be a problem if you care about schema compatibility for your events - and I would care about it in a multi-team microservices setup. Your database schema essentially becomes a contract, your service is not a "black box" anymore. You have locked yourself from the ability to change the schema freely. Also, the messages produced reflect database changes, not domain events. I would prefer to have an explicitly defined interface layer for consumption. At least, use database views as contracts with Kafka Connect.