Hello,
A simple question is it sensible to store commands in the EventStore as well Events?
Why do I ask? There seems to be an opinion that one should also store Commands as well events for completeness if nothing else. Then again do I need to store commands? I have done in the past is there any tangible benefit in doing so?
Thanks.
Paul
Hi Paul,
There’s no reason you can’t store commands either in their own streams or as metadata on the events they are responsible for producing. Although things are named events, we don’t actually care what is inside (the client API for example just takes byte
arrays for both metadata and data).
There can be benefits to keeping hold of commands - regression testing or audit, for example.
Cheers,
James
James, OK thanks for the quick response.
we store all our commands in a separate stream. Storing commands can be useful if you want to find out what ultimately triggered events (trouble shooting or so)
If you do that it’s probably worth storing the ID of the command as a correlation ID on the events produced by it.
I experimented with not only storing but also sending commands via EventStore i.e. a dedicated stream would serve as a command queue. In my experiment there was one command stream/queue per command handler/autonomous component/how do you call it
Interesting how did that work out?
It was only an experiment. I never did anything production on it but it seem to be able to handle ~300 tx/s on my laptop (tx being send command, receive command, generate event, denormalize to ravenDB)
Yeah, we do that.
Bear in mind that an event store is inherently a queue as well - there’s no reason that if you need command queueing you couldn’t do that in an event stream.
Cheers,
James
James, in that case, how would you use ES capabilities to implement competing consumers?
Best,
Rinat
To do competing consumers you probably want something else sitting on top maintaining the position of the current head, there isn’t a nice way to do it using just the event store.
Cheers,
James