Message Sender: Who Sent the Command/Event?

Message Sender

When handling a message, regardless if it’s a command or event, you often want to know who sent the message. Who was the message sender? Not the service, but the actual user who initiated it. If it’s a command then who invoked it. If it’s an event, who invoked the command that changed state within the system that created the event.

This post is in a series related to messaging. The overview is available in my Message Properties post.


The most common reason for wanting to know who sent a message is to determine if they are authorized to perform whatever action is being done by a command. The same can apply for events and event handlers. The task of an event handler may be conditional on who caused the event in the first place.


This can be as simple as including a SenderID along with your message data. A simple example based on other posts in this series:

The SenderID would represent a way for your server to identify who is sending the message. This could be a unique identifier of a user within the system.

ID Token

Another option is to include an ID Token.

ID Tokens are a similar idea but used mainly in token-based authentication. It provides a more performant way of accessing the user profile and access rights. Basically it’s a cached copy of the user profile that was generated when the user authenticated.

One concern here is if you are persisting messages for any length of time, and processing them later, you need to be aware that the ID Token may have expired and may no longer exist in the cache. ID Tokens generally have a lifetime and your message storage may not.

The benefit is access to authorization information that you may need when processing a message. Is the sender authorized to perform an action?

Message Sender

If you have any other ways you like to keep track of the sender, let me know in the comments or on Twitter.

Related Links

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Roundup #66: Capturing the World in Software, Conventional, Polymorphic classes with System.Text.Json, Blazor WebAssembly 3.2.0 Preview 1

Here are the things that caught my eye recently in .NET.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.

Capturing the World in Software

If event sourcing is not scalable, faster, or simpler, why use it?

Event Sourcing gives you a complete, consistent model of the slice of the world modeled by your software. That’s pretty attractive.



After this tweet by Dave Glick, I found this package that I thought was pretty interesting. Check out the twitter thread for a lot of good info.


Deserializing JSON into polymorphic classes with System.Text.Json

While working on SpaceDotNet, a strong-typed client SDK to access the JetBrains Space HTTP API, I came across a scenario to deserialize JSON into polymorphic classes. In this post, I’ll explain how to write a custom JsonConverter for System.Text.Json to help with deserialization for such cases.


Blazor WebAssembly 3.2.0 Preview 1 release now available

Today we released a new preview update for Blazor WebAssembly with a bunch of great new features and improvements.

Here’s what’s new in this release:

  • Version updated to 3.2
  • Simplified startup
  • Download size improvements
  • Support for .NET SignalR client


Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Message-IDs for Handling Concurrency

This post serves as a guide for how you can use a Message identification (Message-IDs) on your messages (events and commands) to handle concurrency.

This post is in a series related to messaging. The overview is available in my Message Properties post.


If you haven’t already check out my YouTube channel.


Each message, regardless of it being an event or a command, should contain a way to identify its specific instance of that message. This is as simple as adding a GUID/UUID to your messages:

No other message (event/command) should ever use this ID (unless you’re also using a message owner). It’s a one time only usage that should be unique.

The producer of the event should be creating this ID before it publishes it. It shouldn’t be hydrated by some middle party.


Most systems support at least once messaging. Meaning, they will deliver a message to the consumer at least once. This means it can be delivered more than once.

Message handlers should be reentrant. You should be able to invoke multiple instances of a message handler concurrently and safely.

Meaning if the exact same instance of an InventoryAdjusted event was invoked twice (with the same ID), at the same time, the outcome would be the inventory on hand would increase by 10, not 20.

We can achieve this by having our message handler use the message ID apart of the same transaction it’s using apart of its state change.

Here’s an example using pseudo C#

The example above is using a unique key on Handler and MessageID columns in the Concurrency table. When we either try to insert the record or commit the transaction, it will fail if the unique constraint fails.


Since an event can have multiple consumers/handlers is the reason why I’ve included the name of the handler as apart of the unique constraint. This is to demonstrate if you were using the same concurrency table for multiple handlers. In the case of event handlers, you want each handler to process the event, but not more than once each.

If you were using this for commands, you wouldn’t need to record the handler, just the MessageID.

Related Links

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.