Async messaging realities

I got a bit of a chuckle from Ayende’s post on time traveling emails. In it, he shows messages in his email inbox received out of order chronologically from when they actually occurred in the real world.

That’s one of the pillars of message-based architectures, that you don’t guarantee when messages arrive, or what order they arrive in. There are a couple of ways we can deal with this, such as the NServiceBus concept of sagas to orchestrate long-running business processes/transactions, where you can keep track of what messages have been received and react accordingly.

One of the difficulties of moving from a synchronous-based message architecture and an async version is that you lose all of these guarantees of synchronous message processing. That’s why it’s not really advisable to view async as a switch to get turned on, since message-based architectures are an architectural approach or style, not an implementation detail. Lots of assumptions get made when you’re writing synchronous code that don’t fly with an async model.

Testing scenarios that involve more than one message getting processed also get more interesting, since testing frameworks are inherently synchronous processes. It’s why you typically see message handlers tested in isolation, rather than a grand end-to-end scenario. Putting a synchronous end-to-end test on an asynchronous process doesn’t really test a production scenario, so its value is at best misleading.

Putting it succinctly – message-based architectures are more than replacing synchronous with async. It’s a mind-shift to a completely different architectural style where your normal rules of engagement are thrown out the window.

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Architecture. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Anonymous

    My favorite solution to this problem is to relate every message to the ones that must have come before them. These predecessor relationships define a partial order among the messages. You enforce a rule between two peers: the source system cannot send the successor before the predecessor. All unrelated messages can be reordered as necessary. This guarantees that messages are received in order when it’s important (like it is in this case), but adds no constraints when it is not important.

  • http://twitter.com/jeremydmiller jeremydmiller

    “Putting a synchronous end-to-end test on an asynchronous process doesn’t really test a production scenario, so its value is at best misleading.”
    I don’t think that’s really the right way to look at the issue.  Every layer of automated tests removes some class of potential errors.  If your asynchronous messaging is really that complicated Jimmy, you definitely wouldn’t want to try untangling problems with the whole shebang before you weed out as many bugs as possible with the smaller, cheaper tests.

    • Anonymous

      That is true, as some of the end-to-end scenarios we’ve tested mostly expose places where we’ve not made the correct assumptions (like the ones Ayende posted above). However, trying to put synchronous tests in place doesn’t ferret these out.

      It’s not that async is complicated – it’s that testing multiple components together in one single test needs to still be based against the realities of distributed systems (the testing I’m talking about is calling a series of handlers synchronously, substituting a synchronous bus for an async one)

  • Pingback: Distributed Weekly 126 — Scott Banwart's Blog

  • G D Milner

    If your going to consider message queues, don’t forget SQL Server Service Broker. It does async, but can insure you receive messages in the order sent, as well. Worth a look!

  • Simon Dowdeswell

    Wow, this was 2 years ago … ok so are there any documented approaches to address this shift in respect to the golden oldie : hidden updates – optimistic locking. Id like to get my hands on the learnings of people who would obviously have encountered all the standard synchronous concerns and developed techniques for the asynchronous alternative. Do any books, sites or blogs spring to mind ?