| This is cool - I love this space and it's indeed pretty complicated. And not that you asked for it but I'll try to add some additional insight. It depends on what you're trying to achieve - are you trying to increase reliability by going
fully event driven? Are you trying to improve just one particular flow? Are you wanting to expose certain data for data science? Unfortunately I don't think there is a good prescriptive answer to this - it all "depends" on your situation. If this is a publicly exposed service - you probably would want to commit/record that a user signed up or posted something and THEN emit an event which will start the chain reaction of other services reacting to the event. If the user created a post - it probably has an ID and you would probably want to communicate that in your event - but if you did not commit anything to the DB, then what are you exactly communicating? Your goal should be to try to be as async as possible - but in some cases, it just doesn't make sense. For example - receive an HTTP request to do something is a 100% synchronous operation. But _after_ you've handled that event - most, if not all things, can be async. Contrived example: 1. User signed up -> UI hits public API which is backed by "Main API service" which commits to DB -> emit USER_SIGNUP event
2. Billing service consumes USER_SIGNUP event and creates a subscription in a 3rd party billing system (and maybe emits another event)
3. Metrics service consumes USER_SIGNUP event and starts recording metrics for this user
4. Audit service consumers USER_SIGNUP event and creates an audit log trace
5. --- Finally, the "Main API" service listens to all kinds of other events that causes it to update its "view" of the user.
What this is hopefully illustrating is that the source of truth is the event and not the DB - DB is just a "view" - by reconstructing the events, you will be able to get back to the current state.Finally, some non-abstract advice - if you're building an event driven system from scratch, I would probably avoid doing CDC as the primary event emission mechanism and instead have your application emit events instead. You'll have a lot more granular control over what is in an event and not be tied directly to the DB schema. Your event schema will evolve and maybe it won't fit what's in the DB. I would lean towards CDC if you are trying to retrofit an existing system. Anyway, hopefully that's a bit helpful! I've been working on this sort of stuff for a while (and actually have a YC-backed startup that focuses on event driven: https://batch.sh). I recently presented on event driven design at a few local meetups and made some slides, it might be useful: https://docs.google.com/presentation/d/1j6Cyid88Ca1shwEN6uyI... |