Should we publish events even though we don’t have any consumers? Some say no, but others think there is value. Let’s take a look.

Future extensibility

• Event-driven architecture allows us to be decoupled and have an architecture we can extend when consuming new events. If we want new events, we go back and add them, what if the events are already there? Just not consumed yet?

• Having events without consumers is something to get your head around, but it would mean you can add consumers in the future with little or no effort.

• If you had a catalog of these events, consumers could come and go as you see fit, that’s the whole point isn’t it?

Write the code, publish the event

• You are in the code anyway, writing the feature, why not emit the event when a business process has been done? Example would be sending an email, you write the code to send the email, then why not raise the event too.

• Publishing events without consumers or any “need” might seem counter intuitive though, this is code and events we have to maintain, so does that come at a cost we have to consider?

• Some brokers may charge for publishing events, so that is also something to consider.

Interest over time

• Today your consumers may not be interested in your events, in the future they might… if the events are already there to be consumed, the effort of integration could be lower?

• Maybe identify which events you want to publish “without consumers”, if they are internal private to that domain, the maybe that doesn’t make much sense? But if they are business domain events, it could?

Summary

Personally, I’m not sure where I sit on this, I can see the value but also any code we write or events we publish we have to maintain. But this is something that I never really considered and come across, so it could be an interesting pattern to explore.

Maybe identify core business events, and raise them, there will be a higher chance of consumption vs private or technical events you may raise.

Extra Resources

• Fundamentals of Software Architecture - Idea came from this book, talking about Event broker topology. Great book to dive deeper.
• Document your events - If you are going to publish future events, it’s worth documenting them for consumers.
• Event Storming - Publishing all events might not be correct, but maybe some core business events might make sense? Use your judgement.