[foz]

This article resonated with me. We are going through a large platform re-launch, and using Kafka and events as a big part of the architecture. After much discussion, we decided against storing events, eventual consistency, or CQRS and so on. Instead, we use events to simply de-couple services. We have strong domain APIs and workers that respond to creates/updates/deletes. We use Kafka to partition things where it makes sense. Just stop there, and there's a ton of benefit. Things get simpler to reason about, easier to test, and result in less dependencies between teams.

[privacyfornow]

We are going through a similar exercise but we avoided the approach of event driven CRUD and stuck to capturing customer's intent and an ability to read its side-effects as our de-facto API.

Consider for instance an API to create and account. Now let's say we want ability to update address. One approach would be an API that changes the address by updating the account but the customer never asked to update the account. The customer wants to change the address. How about we give them the API with change of address request/semantics? This way, no matter what happens, the API and the events remain in sync and you don't expose internal data storage semantics to customers that have no interest in them.