I am building a CQRS-based application with Kafka Streams. For most entities in my application this entails event sourcing: capturing state mutations as events and transforming them into state which can be queried. The events are stored forever so they can be re-processed into state.

However, one of my entities is frequently changing. It is a "Message" type. The end-user makes changes to the message draft in the UI, and these changes are transmitted to the backend as patches. The UI auto-saves after a few seconds of user inactivity. So as the user edits a message, many patch events are generated. I imagine a message may involve hundreds or thousands of mutations.

I am wondering, should I store all these events? I can just as easily only store mutated state for this entity, and save space. Alternatively, I can store all the patch events, but then I have to store all these events that are probably not going to be useful for me to ever replay. At least, I can't think of any reason I'd want to replay them. But... who knows? I can't imagine caring about each message as it evolves, but at the same time I wonder, will I regret not storing these mutations as events?

What should I do? Store all the events or just the state?

  • 1
    If you can't think of a reason to store message draft events, then you don't need events for message drafts. It sounds like a waste of space to me.
    – Dan Wilson
    Commented Oct 17, 2018 at 19:25

1 Answer 1


As is often the case when it comes to architecture and design, the answer here is "it depends".

I don't think that event-sourcing your Message entity from your patch events is inherently a bad idea. But it does sound like it would introduce some complexity to your application, and you should avoid introducing complexity where you don't need it. Make sure this extra complexity actually solves a problem.

So, for example - if your app has a requirement to maintain a detailed revision history of these messages, or to allow multiple people to edit a message at the same time while changes are broadcast to all collaborators over a web socket connection, etc., then event sourcing your persistence makes a lot of sense because it makes these problems easier to manage and reason about.

But if you can expect only one user at a time to be editing a message, and you're just implementing a simple draft feature - then storing your state in a single record you update when a change is made sounds like the more sensible thing to do.

I would avoid making design decisions just because you might need them in the future - in my experience this is one of the most common causes of over-engineered software. Every piece of complexity you introduce into a system comes with a maintenance burden (maintenance of code, infrastructure, time spent training new hires, etc). Err on the side of simplicity unless the requirements warrant a more complicated solution.

In summary: unless you need to persist these events to solve a specific problem (e.g. maintaining a revision history of a message), I would just use a single mutable record per message.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.