Build scalable systems with .NET
When three-tier systems became the rage, it was necessary to change the data access methodology from “open once and hold” to “open and close as many times as required.” This methodology allowed increased scale, but at the cost of both real and perceived performance. It became clear to Microsoft that it would never be able to scale applications to Internet scale as long as its systems required synchronicity. Microsoft Message Queue Server (MSMQ) was released as an additional product but very quickly found its way into the operating system. Now, it is a critical element of the .NET strategy.
The curse of synchronicity
Whether most of us realize it or not, we no longer live in a synchronous world. In a synchronous world, everyone answers the phone when you call. Also, most work is accomplished in meetings and not via e-mail conversations or discussion groups. The problem with synchronicity is that you and at least one other person must be in the same place (physically or electronically) at the same time to get work done. A natural bottleneck occurs whenever work can occur only in a synchronous fashion.
Let’s look at it from a system’s perspective (see Figure A). If you’re running an online commerce system and every database lookup, every order, and every acknowledgement runs through your middle tier to a single database, you have a natural bottleneck. Maybe it performs well now, but if you’re really successful, you have no way to scale the system other than counting on hardware upgrades—a scale-up strategy.
The database becomes the bottleneck as the system grows.
The blessing of asynchronous processing
Let’s look at the online commerce example as an asynchronous implementation. In this implementation, as online orders are received from the Web site, orders are added to a queue that can be processed as database cycles are available (see Figure B). Because the time to place objects on the queue is imperceptible vs. the time it takes to process the transaction in the database, the perceived speed of the system is dramatically increased. The objects used to place orders in the queue can deliver an immediate confirmation back to the customer, such as “your order has been received.”
Requests are placed on the queue and processed by data in the database when the next time slice is available.
The other advantage of this queued configuration is that you can scale the back end in one of two ways. You can employ the same scale-up strategy from the synchronous design and simply add more power to a single back end. But the asynchronous-approach design gives you the opportunity to also employ a scale-out strategy. Instead of having a single back end that processes the queue, you can have multiple back ends picking off queue data and processing it.
It’s important to point out the primary disadvantage to this kind of system design. Asynchronous systems count on near-real-time access to data, not real-time access. For example, our online commerce customers would have to be content with placing an order based on our best current knowledge of stock levels and not an actual transacted exchange in which we committed inventory at the exact point in time that the customer placed the order. In reality, the cost to achieve this kind of precision would make the system too expensive to develop or deploy anyway—so why not take advantage of the scale benefits of asynchronous processing?
Asynchronous implementations in WiredChurch
Queuing theory was never that difficult to grasp, but implementing it using Visual Studio 6.0 and Visual Basic was somewhat of a black art. Now that queuing is built into the .NET Framework at a system level, the process is much more straightforward. But once you get the queue opened, how do you decide the format of the data you place into the queue? Before .NET, this decision was problematic. You had to write both the serialization and deserialization code that placed data on the queue at one end and pulled it off at the other. With .NET, you can either use the native XML objects to do the serialization, or you can place .NET objects in the queue directly, and the CLR will take care of the serialization automatically. .NET was built from the ground up to support the development of asynchronous, disconnected systems.
At WiredChurch.com, we architected the engine processing to take place asynchronously for the express purpose of allowing us to scale as the number of transactions grew. For example, the WorkFlow engine (implemented as a Windows Service) scans the Event database looking for event notifications, invitations, and reminders that need to be delivered in the near future. The Communications engine (also implemented as a Windows service) picks message objects off of the Event queue and delivers them. In our load testing, we could dramatically increase the number of objects we could pull from the Event queue by simply starting another instance of the Communications Engine Windows Service on another machine and pointing it at the Event queue.
In this particular implementation, we want a guarantee of delivery from the queue. By default, message queues are stored in memory. Thus, a machine failure could mean the loss of messages queued but never delivered. By simply setting the Recoverable property of a Message object, we can force MSMQ to create the queue on disk and give us the ability to guarantee delivery. We could also have used Transactional Queues if we needed the queue to participate in an externally controlled transaction, but chose not to wrap functions in transactions. By architecting the system to use queuing as its core, we were able to create a system with a great deal of deployment flexibility (from 1 to n boxes) and scalability (up to millions of transactions).