Herb Sutter wrote an article in 2005 entitled The Free Lunch Is Over, where he points out how microprocessors are approaching a physical limitation in serial processing that will be forcing developers to turn towards concurrent solutions (http://www.gotw.ca/publications/concurrency-ddj.htm).

Newer processors come with multiple cores. To build scalable applications, we can no longer just wait for a faster chip. Instead, we must use alternate, concurrent techniques. This issue is being played out in a whole host of languages. Erlang was one of the first languages on the scene that allowed a telecommunications system to be built with nine 9's of availability, which means about 1 second of downtime every 30 years.

One of its key features is the use of immutable data sent between actors. This provides a nice isolation and allows multiple units to run across the CPU cores. Python has libraries that provide a similar style of decoupled, asynchronous message passing. The two most common ones are Twisted and Kamaelia.

But before you dive into using either of these frameworks, there is something important to keep in mind: it's very hard to test concurrency while also testing algorithms. To use these libraries, you will register code that issues messages and also register handlers to process messages.

It's important to decouple the algorithms from the machinery of whatever concurrency library you pick. This will make it much easier to test the algorithms. It doesn't mean that you shouldn't conduct load tests or try to overload your system with live data playback scenarios.

What it means is that starting with large volume test scenarios is the wrong priority. Your system needs to correctly handle one event in an automated test case before it can handle a thousand events.