I have a multi-layered C# MVC4 web application in a high-traffic scenario that uses dependency injection for various repositories. This is very useful because it is easily testable, and in production we can easily configure the repositories for specific controllers. All controllers inherit from AsyncController, so action methods that return `Task<JsonResult>` or `Task<ActionResult>` truly help our server scale with more users and [solve for the dreaded thread starvation problem](http://www.asp.net/mvc/tutorials/mvc-4/using-asynchronous-methods-in-aspnet-mvc-4). Some repositories use web services, which we can definitely use Async/Await to provide scalability benefits. In other cases, some may use unmanaged services which can't be threaded safely, in which async/await will provide no benefits. Each repository is an implement of an interface, IRepository. In short, each implementation is drastically different in the way it may get data. This configuration is chosen at deployment-time with web.config changes and Autofac modules.

What are some of the recommended ways to implement async/await in an application such as this? To make the pattern fit in my existing application, I have to change the interface to return `Task<MyBusinessObject>`. **But isn't this more of an implementation detail?** I could provide two method stubs, `GetData` and `GetDataAsync`, but to me that wouldn't allow the flexibility I have now with IoC frameworks like Autofac where I can easily swap everything out without having to change code.

One of the Microsoft developers for Async/Await has published a blog post, "[Should I expose an asynchronous wrapper for my synchronous methods?](http://blogs.msdn.com/b/pfxteam/archive/2012/03/24/10287244.aspx)" that sort of goes into the problem. If your async method isn't truly async (providing native I/O benefits) then it really only adds overhead. In other words, it won't provide any scalability benefits.

I just would like how the rest of the Community has tackled this problem.