Our team is mantaining and developing a .NET web service written in C#. We have stress tested the web service's farm and we have evidence that the actual architecture doesn't scale well, as the number of requests are constantly increasing.

We analyzed Martin Fowler's conclusion in this article, and our team feels that migrating to an asynchronous programming model such as the one described could be the right direction to point to for our service too. My question is: do you think that this "switch" needs a complete rewrite of the application? Has been someone of you been able to adopt APM without rewriting everything and has some insight to share?

Thank you in advance

  • 1
    Well, do you actually need to rewrite the whole application? Wouldn't modifying just the bits that are blocking the longest be enough?
    – svick
    Nov 27, 2012 at 10:42
  • Bits that are blocking are calls to external services whose response is needed in order, for our service, to provide a meaningful response. What I am investigating is the better approach to refactor this kind of "dependency".
    – Simone
    Nov 27, 2012 at 11:43
  • But do you have something else to do on that same thread while awaiting the network response?
    – Apoorv
    Oct 28, 2019 at 10:46

3 Answers 3


Use the async and await keywords in C# 5.0. These keywords allow you to insert the async functionality into the method calls that require it, without having to create callback mechanisms. The callbacks are created for you automatically by the compiler, under the covers. This should greatly simplify the refactoring effort.

Anders Hejlsberg describes the async functionality in this video, with a detailed example application and demonstration.

  • Thank you Robert, unfortunately at the moment switching to 5.0 is not an option.
    – Simone
    Nov 28, 2012 at 8:48

If moving to C# 5.0 is not an option, then I am afraid you will have to fallback to the more traditional approach of using callback functions. I once migrated a thick client application using this approach.

Every application is different so it is hard to predict how much rewrite you'd need but in my experience, it was never overwhelming. What took more effort was the gotchas that come with asynchronous programming. I can highlight two:

  1. First and foremost, you'd need to think about your application flow and figure out which parts of the application should remain disabled when an async operation is running. If an application has not been designed with this in mind then it can take a lot of effort to maintain state information and logically grouping the sections that should go disabled together etc. If your application is a server, then you may not run into this complication.

  2. Second, and this has universal applicability, you will need to come up with a way to recover the information from different BeginAsync(...) calls. One way to do this is to pass the function and its arguments in the call back object itself. You get a reference to this object in the EndAsync(...) method. An obvious gotcha there is to make sure you are able to distinguish one BeginAsync(...) call from another one on the same method.

I am not saying that you can avoid thinking of these issues with the newer API. These are common issues with async programming in general --in any framework or language. But once you write some async code and get it to work correctly, it becomes second nature to think this way.


Bits that are blocking are calls to external services whose response is needed in order, for our service, to provide a meaningful response.

Is there more processing you could do while waiting for the response from these external service calls? If not then you are out of luck async will only buy you performance if you are able to do more in parallel.

On the other hand if these external services are the only thing needing to be executed in parallel, I would look into futures, they seem like a good fit for kicking off a service call then doing something else while waiting for the result as well as the fact that they would be minimally invasive to your current design.

  • Thank you, I will investigate further on futures. By the way, there's not much processing that I can do while waiting for external service's response and we found..
    – Simone
    Nov 28, 2012 at 8:42
  • @Simone Then parallel programming isn't going to help you.
    – Apoorv
    Oct 28, 2019 at 13:24

Not the answer you're looking for? Browse other questions tagged or ask your own question.