Event Store as a Messaging Topology - Beginners Question

EventStoreDB
#1

Hey guys!

I’m new to Event Store but I’ve been scouring the internet for implementation and documentation and I’m loving it so far.

Question though, Event Store seems to be able to take the place of an event message broker. My question is, do most people use Event Store in place of an message broker like Azure Service Bus for example? And how are customers handling their command messages with Event Store? I know that Event Store and a message topology like Azure Service Bus are fundamentally different, but it looks like you can get away with replacing Azure Service Bus with Event Store for most things.

Are customers usually using a persistent subscription to handle their command messaging, or supplementing Event Store with other technologies? Any help would be really appreciated.

Thanks :slight_smile:

#2

People are doing … both.

Both can make sense. What are your expectations? What is throughput? What about latency? How many nodes? Is everything intended to be one-way?

One a side note … this is known as “one way commands” I generally would not use them but instead have the client raising events (terminology/wording difference). The domain becomes a downstream event processor.

#3

Yeah so that was the one use case that looked like it was missing from the product. The reason I was worried that they’re not available here is because commands are usually intended for specific handlers, or you might want a response indicating failure or whatever, and still get the resiliency of dead queues and retries. That’s my impression at least and I know you compensate with specific event streaming patterns but I’m wondering what best practices are in the wild.

So as far as expectations, I’m learning this for personal growth, but let’s say that I’m writing an OLTP system where demand is seasonal and volatile and transactional speed is incredibly important. There will be sagas and process managers who will coordinate events and send commands, and hydration for aggregates is required. The tactical pattern would be event sourcing CQRS DDD, and some polyglot persistence like elastic search, graph database, document storage. Some might be done through ETL or through handling events and creating read models for the bounded context. Obviously there could be other systems using different event streaming, messaging topologies like Kafka or azure service bus or event hubs.

Obviously that’s a lot of hypothetical information and I’m not trying to get anyone to solve my problem for me but hopefully that helps. Was hoping to get some opinions from the community here about whether my concerns for commands functionality is easily handled by functionality here or if I should get another tech to compensate for best practice.

Thanks guys

#4

“Yeah so that was the one use case that looked like it was missing from the product. The reason I was worried that they’re not available here is because commands are usually intended for specific handlers, or you might want a response indicating failure or whatever, and still get the resiliency of dead queues and retries.”

What is missing from the product? One-way commands have no support nor require any support in the product. This is all stuff well above eventstore.

Maybe I am misunderstanding something?

#5

No you’re probably not misunderstanding I probably just Don’t have a great understanding of everything yet. For me it seemed like 95% of everything I needed here for a messaging middlewear was in event store and it would kind of be a waste to use another tech just for the request/reply or one way command.

So I think what I’m hearing from you is that sending commands to the event stream and subscribing is how people normally handle commands and in your opinion that’s preferable?

#6

People do this … But only with one-way commands. You can’t reply “yes it worked…” or “it failed due to error 1245 item was not a currency …”

Well you can but its a completely different mechanism. It usually starts a conversation. EG: I receive and I give them a stream where results can be subscribed to etc …

For many the request/reply of your app is something like … http :slight_smile: There are uses especially with atom feeds where eventstore is the backend (there is no other backend the clients just talk via atom feeds!)

#7

Yeah that makes sense. Especially in the scenario where I outlined we would want to fail quickly and send the client a response so a command hanging around in a dead letter queue wouldn’t make much sense, and just a retry strategy would be best.

Thanks Greg :slight_smile: