Property encryption is one of my favorite NServiceBus features in that it provides a pattern for implementing message encryption as well as providing a concrete basis for addressing the concerns of compliance and security teams. Additionally, once your endpoint conventions are configured, it is easy to live with since it gets implemented only where necessary and in a consistent way.

One of the foundational features of NServiceBus is the support of multiple queuing technologies known in NServiceBus parlance as a Transport. NServiceBus transports encapsulate the logic required to connect to their respective queue technologies to produce and consume messages.

Testing is one of the more challenging aspects of message based systems and is probably one of the top reasons it is common to see http endpoints instead of messaging in microservices.

There are a number of subtle but important aspects of message based systems that are not apparent until after you have started building one and running it in production. One of those aspects is message headers. NServiceBus message headers contain metadata about each message that will help you correlate, route and trace the history of a message in your system.

Message retries are one of the most powerful patterns in message based systems. Retries are probably one of the more compelling reasons to use a message based architecture and make a system that uses them significantly more durable and accurate.

As a software engineers we all know the requirements will change over time. At some point you will need to become comfortable with versioning your NServiceBus messages to adapt to those changing requirements. When you start thinking about the nuances of deploying endpoints that need to handle messages of different versions in flight or in an error queue waiting for retries it can be overwhelming at first. Luckily, there is a straight forward and relatively painless way to make changes to your contracts that will enable your endpoints to process old and new versions in parallel.