Event-driven systems, written carefully, and running on capable hardware, are hard to beat on performance metrics. This is why node.js is so popular these days.

Interestingly, this was the programming model used by the Inktomi Traffic Server (http://en.wikipedia.org/wiki/Tra…), which smoked all competitive benchmarks for proxy servers when it ruled the roost during the last dot-com boom.

But what a difference a decade makes.

Building an event-driven infrastructure is hard

Writing an event loop, establishing conventions, building debugging tools, testing and refining – this takes a lot of time, effort, and indeed, tons of intellectual capital. At Inktomi, we built all of this up from scratch, and trust me, there were furious technical “discussions”, especially when integrating with the many upstart startups that were acquired and assimilated.

Node.js? Why, the browser context already provides the event-driven infrastructure – that’s how javascript code runs on webpages anyway; it’s no big deal. Which brings me to:

Training engineers on event-driven programming is hard

No one teaches event-driven programming at school, it’s still all procedural, except for a few exotic classes on functional programming. When new engineers were hired at Inktomi to work on the core event-driven system, a lot of training and mentoring was involved to make sure they didn’t stall the system by, say, trying to do too much when reacting to a given event, stalling the system.

Node.js? Well, the early majority of developers using the system are frontend developers – who have trained at the school of hard knocks, writing javascript-heavy websites – which, of course, is event-driven programming. Callbacks, bite-sized computations, yielding, managing user experience while waiting for a backend call – all of these are techniques that the new breed of frontend engineers are very well versed with – and so the transition to a similar system on the server is trivial.

So, ironically, the prevalence of AJAX has trained a whole cadre of frontend engineers to write highly performant backend code (within the context of an event-driven system of course).

Writing high-performance systems for big-iron is hard

How do you squeeze the most performance from big-iron systems? Easy – use an infrastructure that is supposed to blaze on the very lowest-end of machines, and then give it gigs of memory and tens of cores of CPU!

This is funny. Scores of engineers at Apple, Google, Microsoft and Mozilla are in a race to build the fastest possible runtime for Javascript – so that even browsers running on an IBM XT can render the most awesome AJAXy websites without problem.

Then, we take that same infrastructure, and with Node.js, run it on server-class hardware! All the micro-optimization done to the runtimes, running on a 1000x more powerful computer – is it any surprise that node.js rocks out AWS EC2?

—

In a decade, by a quirk of history, we’ve ended up with a whole cadre of event-driven programmers, a highly performant, well-tested runtime for event-driven programming, and brought both of them together to build a whole new generation of server technology. It’s like Back to the Future!

Amit

Post on Quora