The Asynchronous Services Analogy

Today I had a chance to sit through a sneak preview of Theo Schlossnagle’s new talk Scalable Internet Architectures, to be delivered next week at Velocity 2009 (Dev sessions are an underrated side benefit of working at OmniTI). As always Theo packs a lot of good information into his talks; I could probably do blog entries on half a dozen ideas I jotted down; but I wanted to highlight something that he mentioned with regards to scaling websites via asynchronous services. The basic idea behind finding services that can be turned from synchronous actions to asynchronous ones typically means finding those actions for which delayed action from the point user input does not manifest as a degraded service to the end user. Not every service can fit into this category, and perhaps the best analogy falls once again on the old banking transaction. The banking transaction is the classic fallback for explaining transaction semantics and the properties of ACID. The argument goes, when I transfer money from one account to another, I want the withdrawal from the first account, and the deposit into the second account, to take place simultaneously, with no possibility for one to occur without the other. This also works as a great example of services that can be made asynchronous, or not. Consider this, when I do my bank transfer, the withdrawal and insert are two things that I really do not want to happen asynchronously. As soon as you take the money out of one account, you better put the money in the other account right now; not in a few seconds and not eventually, but right now (thank you very much!). That said, the email you’re going to send me as a receipt to that transaction, that could be done asynchronously. Considering all the hops between my transaction and the email arriving in my inbox; formulating the email, sending it to your mail server, having it get to my isp, and then eventually winding up in my mail client; pulling that out of the critical path of my bank transfer seems like a perfectly acceptable solution. And incidentally, it will help you whether you’re sending those emails in the middle of your application code or via database triggers. Of course these are the types of things you need to seek out as you scale your application to millions of users. Sometimes the decisions are straightforward based on what you’re doing (email can almost always be made into an asynchronous operation), sometimes that decision is determined by how hard it is to keep something synchronous; does your tag count on the home page really have to be up-to-the second accurate? consider that means you’d almost have to serialize tagging, not terribly enticing, eh? Anyway, that’s just one of the topics in the talk, and a great analogy that should make the concepts of asynchronous vs. synchronous services straightforward for any developer.