Skip to main content

Particular Software Blog

Popular topics

Latest articles

  • Modern NServiceBus messaging on IBM MQ

    Written by Irina Dominte, Dennis van der Stelt, and Ramon Smits on October 6, 2026
    An illustration of enterprise messaging evolution. IBM MQ systems on the left connect through the cloud to NServiceBus on the right in a brighter, developer-friendly scene.

    Have you ever used a green screen application backed by an IBM mainframe? Or watched a store clerk try to navigate a green-screen point-of-sale system? One of us authors (we’ll never admit who!) remembers almost taking down an entire call center on one of those systems, but that’s another story. 1

    Those apps and systems are about as far away from “modern” as you can get, but they run real business: they move orders, settle payments, and sync inventory. Companies that can’t afford downtime depend on them all day, every day. They carry decades of business rules that are hard to replace and risky to rewrite. So most teams don’t get the luxury of choosing between “old” and “new.” They’re trying to keep mission-critical systems in place while giving developers a better way to build with and around them.

    Our new IBM MQ message transport bridges the old and the new. IBM MQ keeps doing what it’s always done well: durable, reliable message delivery. NServiceBus adds a modern programming model and operational tooling that many teams would otherwise have to build by hand: handlers instead of receive loops, built-in recoverability, and visibility across service boundaries.

    Read more

    1. OK fine, you clicked, you asked for it! I was a young, enthusiastic software developer maintaining software that told call center operators which company a caller was trying to reach. My colleagues uploaded files from the command line, but I installed WS_FTP, one of the first FTP clients for Windows (It was great, look it up!) on Windows 3.11 and proudly clicked through the mainframe's folders instead. Then I accidentally dragged one folder into another. Whoops. I had no idea which folder I'd moved, so I did the only natural thing I could do: I told no one. The mainframe slowed and slowed until someone investigated and found the misplaced folder. The machine needed a restart, which took four hours. Calls kept coming in the whole time, but with the software down, operators had to answer the phone without knowing which company they were representing.

    2. For a good primer on these two problems, check out our blog post Banish ghost messages and zombie records from your web tier that describes our transactional session feature that you can also use with the IBM MQ transport.

  • Hosting the Particular Platform with Aspire

    Written by Jo Palac, Mike Minutillo, Rhys Bevilaqua, and Warwick Schroeder on August 18, 2026
    Cartoon illustration of a single Aspire AppHost containing the Particular Platform components, with a discarded docker-compose file beside it

    When it comes to developing distributed systems, anyone can spin up a handful of containers. The part that causes us to bang our foreheads on the table is getting the dozen or so settings configured correctly across all of them. This means using the same transport, mapping queue names, and configuring the correct URLs between ServicePulse and each ServiceControl instance. Now, AddParticularPlatform quietly does all of it for you.

    Leave your forehead out of it.

    Read more

  • Running multiple NServiceBus endpoints in Azure Functions

    Written by Daniel Marbach on August 4, 2026
    An Azure Functions party showing many celebrating dogs, representing multiple endpoints running within a single Azure Functions app
    An Azure Functions party, inspired by the "dog party" at the end of P.D. Eastman's Go, Dog, Go!

    Azure Functions makes it easy to deploy multiple triggers side by side. With support for multiple NServiceBus endpoints in a single process, the new Functions integration brings that same flexibility to message processing: related endpoints can run in one Functions app without sharing handlers, configuration, or dependency injection registrations.

    You can now make deployment much easier while preserving endpoint boundaries. HTTP and timer triggers can also send messages through named send-only endpoints without requiring a companion host.

    That sounds like a party to me! Plus, each endpoint arrives with a “plus one”: the Service Bus trigger that feeds it messages. Here’s how we made room for them all in one Azure Functions app.

    Read more

    1. …which included the name "Worker" because the "isolated worker" model replaced the earlier "in-process" hosting model that has been retired by Microsoft. Creating a new package also allowed us to unify the naming around Functions now that the distinction between in-process and isolated worker is no longer necessary.

    2. One day, we believe ahead-of-time compilation will be a killer feature for Azure Functions hosting, as serverless environments start instances on demand, so cold start time and total memory footprint are key. The thing is that the Azure Functions SDK doesn't support trimming or native AOT yet.

  • Convention-based message handlers

    Written by David Boike on July 28, 2026
    The suit coat, vest, shirt, and tie representing the ceremony and strict requirements of a message handler implementing IHandleMessages, while a utility jacket depicts the flexibility of new convention-based handlers.

    In the previous post, we talked about how NServiceBus version 10.2 can now host multiple endpoints within the same host process.

    Since we’re already talking about removing constraints and limitations from the past, why don’t we talk about another long-standing NServiceBus requirement…

    What if you didn’t need IHandleMessages<T>?

    Read more

    1. By the way, some people really love this, but there are others that really hate it. It doesn't exactly rise to the level of tabs vs. spaces, but feelings on both sides are very strong.

    2. We already had to do that once in NServiceBus 6 to support async/await. We were forced to change from synchronous void Handle(TMessage) to Task Handle(TMessage, IMessageHandlerContext), and it was so painful we never want to force that kind of change on our users again if we can help it.

    3. That was already a gargantuan project that required changes to nearly every single async method in every one of our repos.

    4. A separate diagnostic NSB0025 does the same for sagas.

    5. I just realized how old I am getting when I recalled that Visual Studio didn't always do that. You needed to get ReSharper for even that simple refactoring.

    6. It even adds the required namespaces!

    7. Oh my gosh, please don't, refactor that mess!

  • Multiple endpoint hosting

    Written by Daniel Marbach on July 21, 2026
    Multiple cats representing messaging endpoints, all chasing envelopes that represent messages

    Throughout the history of NServiceBus, there has been a fairly standard practice:

    1 endpoint == 1 queue == 1 process

    The endpoint owned everything within the process boundary and used assembly scanning to find and wire up all the things that make up that endpoint. While you could use “satellites”, you really couldn’t put more than one full endpoint inside a process boundary.

    But… what if it didn’t have to be that way?

    Read more

    1. …because there are a low number of endpoints that happen to be scaled out to multiple tenants, using the same code but deployed separately due to different configuration and scalability needs.

    2. …and dare I say, more fun?

    3. This is because source generators do not perform well when driven off implemented interfaces, so Microsoft recommends you Never Do That®. Scans using an attribute are the fastest and most optimized code path, which is important because a source generator can technically run every time you press a key in your IDE.

    4. Or even most?

  • Redesigning the NServiceBus pipeline yet again: The nerd sniping of Daniel Marbach

    Written by David Boike and Daniel Marbach on July 14, 2026
    Two fish, one representing a trim-capable pipeline, the other representing an impossible performance improvement, both eyeing a fish hook lowered into the water

    Daniel and I 1 have worked on improvements to the NServiceBus pipeline multiple times before: a 10x speed-up in 2017, and another 5x improvement in 2022. We thought we were all done with that.

    So, quite unexpectedly, this is the story of how I accidentally nerd sniped Daniel into redesigning the NServiceBus pipeline yet again.

    One little comment from me, and Daniel made the pipeline start 330x faster and run 25-29% faster on the success path, while still producing zero allocations along that path.

    Do I feel a little bad about it? Yes. Will I get over it? Also probably yes.

    Read more

    1. David, your author, and Daniel's nemesis. Ok, not really. Daniel and I are great buds, but I digress…

    2. And given that, it logically follows that one of the first things to get trimmed away would be the compiler code itself.

    3. If you analyze it another way, there were 5 years between the first two performance enhancements, and then 4 years between the previous one and this one. Assuming a linear decrease in time between pipeline improvements, can we expect another groundbreaking performance enhancement in just 3 years? You'll have to check back with us in 2029 to find out.

    4. Andrew Lock does a fantastic job explaining new .NET features like this one, but an even better job at highlighting why it matters. If you don't follow his posts, you should!

    5. If you're interested, our code is open source, you know…

    6. Our first iteration of prewired invokers used exactly that: 130 lines of hardcoded switch-case factory code that mapped each context type to its corresponding InvokerNode<TIn, TOut type.

    7. Daniel had his revenge on me during the editing of this post. After I recalled the XKCD origin of the term "nerd sniping" I was drawn in by the "infinite grid of one-ohm resistors" (my original degree was in Electrical Engineering) sending me far down a rabbit hole that included a trip to Physics Stack Exchange and, far too many minutes later, a realization that I no longer remember enough calculus to understand the math going on there.

  • Preparing NServiceBus for trimming and AOT

    Written by Daniel Marbach on July 7, 2026
    Trimming a tree

    Trimming a tree blindfolded is probably not the best idea in the world. The best-case scenario is “at least the tree didn’t die.” The worst-case scenario is a trip to the emergency room. 1

    The .NET ecosystem is getting into the tree-trimming business (in a manner of speaking), and we’re starting to make changes to NServiceBus to ensure you won’t be caught trimming your apps with a blindfold on.

    Trimming and ahead-of-time compilation (AOT) reward code that the compiler can see. That changes some of the design assumptions for a framework like NServiceBus, which until now has relied on runtime discovery to maintain a productive developer experience.

    Read more

    1. Those scissors are sharp!

    2. This is because source generators do not perform well when driven off implemented interfaces, so Microsoft recommends you Never Do That®. Scans using an attribute are the fastest and most optimized code path, which is important because a source generator can technically run every time you press a key in your IDE.

    3. To check a package for yourself, navigate to the NuGet package page, click the Open in NuGet Package Explorer link such as this one for Npgsql, open the lib folder, then (generally) the latest net*.0 directory, and then click on the assembly DLL. Now look below for any AssemblyMetadata values. A package is trimmable if the key IsTrimmable has value True, and is AOT-compatible if IsAotCompatible has value True.

    4. That's right, if the source generator generates code that refers to your handler type, it will no longer be flagged as having no references!

  • Our new Small Business Program

    Written by Udi Dahan on October 29, 2025
    Sketch image showing gradual discount levels
    Update 2026-03-31: Particular has contributed the SmallBusinessProgram repository to the Use What Works community organization. Update 2026-01-15: Following Dylan Beattie’s video about licensing models in the .NET ecosystem, and the discussions it triggered in the community, we have decided to open-source our Small Business Program. We’re making it available under the CC-BY license so that everybody can reuse, mix, and modify it without worry of copyright infringement. We hope this will make it that extra bit easier for others to… Read more

  • AWS Enhancements

    Written by Daniel Marbach, Laila Bougria, and Mauro Servienti on October 14, 2025
    Cartoon image conveying building construction around AWS

    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 more

    1. 30 seconds by default

    2. Check out our blog post Infrastructure soup or our pipeline behavior documentation for more info.

  • Resistance is futile...unless you have ServicePulse

    Written by Dennis van der Stelt on September 8, 2025
    Screen on the Star Trek Enterprise providing an imagined futuristic view of ServicePulse
    ServicePulse helps you recover from failures

    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.

    Read more

    1. In the 24th century, this would probably be NServiceBus version 168?

    2. Do you think that's still a thing in the 24th century?

Older posts