CQRS points us at a clear command contract with ms and handlers, and read store pattern erases the challenges of batching transactional data updates to analytical stores.

I feel like CQRS with event sourcing is a natural fit when your primary challenge is transaction diversity and complexity.

The system must support complex transaction workflows involving many participating services, both internal ms and external services. Some synch, some asynch. The complete record of state changes for debug, reprocessing, and audit trail in compliance heavy env is killer app.

With the body reserved purely for state, message replay into a state store is seamless, eliminates any required semantic coupling in consumers, and any irrelivant fields in your state store.

So much cleaner. (2/2)

Wow I was literally just thinking about this and set it as the next thing to tackle. I have an emerging architecture where the other way around fits. Thanks for the thoughts.

Just need to flesh out the constraints on producer and consumer relationships to topic partitions for message ordering guarantees and concurrency control without hitting a dead end. Feels close. (3/3)

Manage the eventual consistency state topics with state versioning in commands and OCC in command handlers. Build on Kafka Streams or Faust Streaming to materialize state from stream. Apply saga pattern to orchestration or choreography of complex transactions across microservices. (2/3)

Mmm. How you doin