Home page 
Check out the latest enhancements to NServiceBus support for AWS. All of these updates aim to give you more control, fewer surprises, and a smoother experience when building distributed message-based systems on AWS.
Read more30 seconds by default
Check out our blog post Infrastructure soup or our pipeline behavior documentation for more info.
We are the Borg. Your messages have failed and will be assimilated. Resistance is futile.
Distributed systems are a lot like Star Trek’s infamous Borg Collective: massively parallel, highly interconnected, and sometimes, drones services go down or are inaccessible. After all, even with a galaxy-class architecture, things sometimes go wrong. Messages can fail due to transient errors, unexpected exceptions, or configuration hiccups. However, well-designed distributed systems take a stronger cue from the Borg; they are built to be resilient. But how? Let’s explore a more peaceful quadrant of the galaxy to illustrate how this works.
In the 24th century, this would probably be NServiceBus version 168?
Do you think that's still a thing in the 24th century?
In distributed systems, coordination is hard—really hard—especially when both parties depend on mutual confirmation to proceed, but there’s no guarantee their messages will arrive. This classic dilemma is known as the Two Generals’ Problem. Like most problems in computer science, it’s easier to understand when explained with lasers, spaceships, and sarcastic smugglers.
Let’s set the stage: It’s Return of the Jedi and the second Death Star looms large over the forest moon of Endor. The Rebel Alliance’s plan hinges on a synchronized attack — Han Solo leads the ground team to destroy the shield generator, while Lando Calrissian leads the space fleet to attack the Death Star itself.
For the mission to succeed, both parties must execute their part of the plan. If either side decides to abort, the other must as well, or it will be a disaster.
And here’s the twist: Han and Lando can only communicate through spotty, insecure rebel comms. Sound familiar?
Read more
It doesn’t matter if you’re developing using MVC, WebAPI, or Razor pages—you want your controller code to be nice and lean. The more bloated that code is, the more coupling you have, and the closer you are to an unmanageable big ball of mud.
You probably already know that, but I’d bet not all of your controller code is as lean as you’d like it to be. Is it?
So that leaves the question… How do we get there?
Read moreIn a good way. Boring code is reliable code!
It's almost always the tables!
Implementations exist for SQL databases, Cosmos DB, Azure Tables, DynamoDB, MongoDB, and RavenDB.
Every software system evolves through different stages of complexity. They start simple—attempting to solve a problem that might not yet be well-defined. As they grow, problems become more well-defined, and then they grow some more. Just like with lanky teenagers, this growth can sometimes cause growing pains. A skilled architect knows how to watch for the signs of these growing pains and how to apply more robust architectural patterns to ensure the system can continue to grow and flourish.
This post is the story of the growing pains experienced by our friends at VECOZO, a system integrator that ensures safe communication between numerous healthcare-related companies. They knew it would be irresponsible to design every piece of software to handle massive scale, even if it only had a few users. So, when the architects started to see telltale signs, they knew it was time to deploy more robust architectural patterns.
As you read on, maybe you’ll find that some of the challenges they faced sound familiar…
Read more
Migrating a message-based system from on-premises to the cloud is a colossal undertaking. If you search for “how to migrate to the cloud”, there are reams of articles that encourage you to understand your system, evaluate cloud providers, choose the right messaging service, and manage security and compliance.
Curiously, what’s often missing from the discussion is details, like how to handle all the other on-prem systems that integrate with your system, both upstream and downstream, that can’t be upgraded at the same time. This gets even more tricky when those integrations are over on-prem-only technologies, like MSMQ, that don’t integrate out-of-the-box with cloud alternatives like Azure Service Bus or Amazon SQS. It’s as if they’re saying, “Have you documented your system? Great! Have you chosen a cloud provider? Awesome! Do you have all the services in place? Wonderful! Now go rewrite all your code… we’ll wait…are you done yet?..What are you looking at me for? I’ve already told you to plan carefully, I can’t do EVERYTHING for you”
Read more
We all love building greenfield projects. 1 But inevitably, starting a new project involves lots of meetings with business stakeholders to hash out initial requirements and canonical data models. Those are…not so fun.
When one of those meetings occurs after a carb-heavy lunch, it’s easy for your mind to drift away…back to those university lectures about entity design. Think of the nouns and what attributes they have. A dog and a cat are both animals and have 4 legs. Except now it’s Customers, Orders, Products, and Shopping Carts.
Is this the best way to build a system, though? Didn’t we do the exact same thing on the previous greenfield project we’re now rewriting? Surely we won’t make all the same mistakes we made last time…right?
Read moreOr a rewrite of the greenfield project from 5 years ago, but that's another story.
We'll know the project has hit the big time when we can no longer make the diagram fit on one page and remain readable. That's OK. I hear the copy shop down the street has a large format printer we can use…
Spoiler alert: sometimes, these inventory numbers are totally fake and designed to scam you into feeling more pressure to buy! In other cases, you can continue to sell even when there's negative inventory by putting an item on backorder and notifying the customer when it becomes available. Here, let's pretend that we need this inventory to be accurate, at least as much as eventual consistency will allow.
Anti-requirements or antirequirements, with or without the dash. Or, you can call them de-requirements or even dequirements? We'll stick with anti-requirements in this post.
For another example of this kind of decomposition, check out Putting your events on a diet.
You don't always have to ask them about anti-requirements directly. Using anti-requirements as a mental device on your own is just as valuable.
Never ever had so much fun with a thesaurus. 😉
Be careful with this anti-requirement too. In some contexts, inventory and shipping time could be related if a predictive algorithm determines that items with low inventory are likely to oversell, which means we can't promise 24-hour delivery. As always, it depends, so ask the business stakeholders to be absolutely sure.
Harvard Business Review says the [most productive meetings have fewer than 8 people] because the number of people attending tends to have an inverse relationship with meeting productivity. And honestly, even 8 feels like a lot if you want to accomplish anything!
Both terms have been abused so much they're almost meaningless, so take your pick.
In vertical slice architecture, each service is responsible for all of the traditional "layers" (i.e., UI, Application, Domain Logic, and Database) within the slice that can be defined, in part, using anti-requirements. Check out videos on vertical slice architecture by Jimmy Bogard or Derek Comartin for more.
This video uses the same shopping cart example as this article. Remember that the ViewModel composition code shown in the video is already out-of-date. Using ServiceComposer is a lot more user-friendly.
When code breaks, our first move is carefully inspecting the call stack. It helps us find the needle in the haystack by understanding how, where, and why the failure occurred, including how we got there.
However, in a message-based system, we no longer have a single call stack. We’ve exchanged it for a haystack of call stacks, which makes finding the needle (the root cause of the failure) even more difficult.
Read moreThe .NET tracing API for OpenTelemetry uses the term Activity instead of Span from the OpenTelemetry specification. However, throughout this post, we will use the OpenTelemetry specification terminology of Span and its related terms.
Even .NET Framework
This package has been deprecated for NServiceBus version 8 and above in favor of the built-in implementation.
You’re standing in the airport, waiting to pick up your bag. Did you ever stop to think about all the software systems involved in tracking your luggage on your journey? From the moment you drop it off at your departure airport to the moment you breathe that sigh of relief as it shows up on the baggage carousel is a complex story of messaging and system integrations.
I recently had the opportunity to chat with the lead developer for the luggage arrival system at a major Asian international hub. 1 He told me how using NServiceBus made it possible to get all the systems in the airport to work together reliably.
Read moreUnfortunately, it's impossible to name names without getting a bunch of lawyers involved. The names have been changed (well, just omitted) to protect the innocent.
Well, hopefully. The bag source messages really represent the bags checked in from the outbound port, not the aircraft. So there's no way to know whether a bag made it onto the aircraft! 😬
NServiceBus endpoints have always been good at running reliably, but they could have been better at stopping. And when you want an endpoint to stop, you want it to stop…now.
In NServiceBus 8.0, which is now available, we have introduced support for cooperative cancellation, which will give you greater control over how an NServiceBus endpoint behaves when you need to shut it down.
Let’s talk about what cancellation is, how it relates to NServiceBus, and how we’re delivering cancellation in NServiceBus 8 without forcing a massive breaking change on your existing systems.
Read moreIf you remember the upgrade to NServiceBus 6, we had a similar interface change to support async/await. While we still stand by that change now, it's not something we care to repeat.
This technically means anywhere one of your method parameters implements ICancellableContext. This is a new interface we added as it includes both IPipelineContext (from which IMessageHandlerContext derives) as well as IBehaviorContext.
...or behaviors. But message handlers are far more common, so we'll focus on them here.
NServiceBus already has an analyzer that makes sure you don't forget to await a Task returned by one of our APIs, and a suite of saga analyzers to make saga development easier.
Come on, admit it, you do. I do too. Let's just all agree most of those messages aren't worth our time, right?
silent and none may sound like the same thing, but they're not. If you choose silent, you don't get any squigglies or dots in the code, but if you hover your mouse over the code, you'll still get the analyzer message. If you choose none, then the analyzer won't report diagnostics at all.
