In the past week+ the whole business about Twitter scalability & reliability came to a head.
Yet, despite infrastructure that is visibly “hitting the wall”, now it appears that the company is gaining interest in a funding round at a decent valuation (maybe even signed one, but more on that later).
How is this possible?
I think the answer to this is that
- Building a scalable micro-blogging site is not that hard
- There’s hoped-for value in all that traffic
Building a Scalable Micro-Blogging Site
If you’re starting from a clean sheet, the answer is that it’s not very hard to make a scalable micro-blogging platform. Unlike some recent comments, the solution is not rocket science.
The key is simple:
- take the database out of the flow of messages. Of course, you still write to the db as it’s able to keep up (for archival purposes), but that’s about it.
- create objects that stand-in for each subscriber, whether follower, followee, or both
- have them interact over a simple pub / sub model, reliable in-memory space, or both
- wrap all this in our application fabric to handle organization, reliability, and operations as you scale
- deploy on commodity (in-house or cloud)
Of course this becomes pretty hard if you’re committed to Ruby on Rails, which is very tied to a database. Terrific for some stuff, not so good for high-volume messaging apps.
Are there other approaches? Sure, but nothing this conceptually simple, easy to implement, cheap to deploy, and brain-dead simple to operate.
What’s a Twitter to do?
Arrington posted some speculated usage numbers today that are useful in validating this approach. Remember that all of this is greatly aided by two simple facts:
- twitter messages are limited to 140 characters
- delivery expectations for SMS etc. are modest, at best
So easy to deliver, forgiving with regards to when they get delivered … this is really fairly straightforward.
Of course, I’m sure the first order of business for the new technical folks is to stabilize the existing platform … then get to work on something that can be counted on for 10x 100x 1000x this amount of traffic.
Final Thoughts
The very fact that Twitter is able to raise a round (at a decent valuation) despite the obvious problems is a vote from the venture community that the business will be worth building (traffic is decent, it is hoped to grow significantly, will be of some TBD value to someone), and that building a real infrastructure is eminently doable.
Give us a call!
{ 3 comments }
I put up a similar post a few days ago… http://www.themcwongs.com/mcblog/2008/04/twitter-jabber-stability-shoul.html. Twitter is a message router, not an MVC app. The focus recently is “oh, they use rails, that’s why they don’t scale…” but as Twitter founder ev points out (http://twitter.com/ev) there is a lot of code there that isn’t rails. Striking the appropriate balance is what’s key, and shifting more to the approach outlined here is very reasonable.
Another FUD article from someone who obviously knows nothing about Rails.
As a developer, I would never, in a million years, write a blog post supposing that I know how to build an application better rather than the actual developers who have worked on it for the past two years.
What if I told you how to do your job? What if I went into that post about your Drupal commenting being buggy and told you, “Yeah, it’s really not that hard to get Drupal commenting to work. Just follow these three one-sentence steps and it’ll work right quick.”
You never know what goes into any project or application unless you actually work on it. Or, at the very least, do at least some research about it. If you did, you would have found out that Twitter’s core does in fact run on a message queue system that’s not Rails at all, but pure Ruby:
http://dev.twitter.com/2008/01/announcing-starling.html
Daemons, asynchronous messaging, memcached. Sounds like your first three bullet points right there. Pardon them if they don’t follow your fourth.
Comments on this entry are closed.