Scale is hard.
Really, really hard. Just ask Twitter, after the tough couple of months they have been having. Twitter has had to repeatedly slash the rate limit on their APIs in order to cheat death-by-site-down. This makes me think of two things:
1) Scale is hard
2) API rate limits are an embarrassing necessity if you aren't good enough at #1
What's so hard about Twitter, you might ask? Many of us who call ourselves software engineers have tackled functional problems that would make the Twitter engineers weep. All Twitter does is take a 140 character blurb and stick it in a database. That is it. Really. It isn't rocket science. I'll wager that you or I could have a functional prototype done this afternoon, starting from scratch. We'd sit back and pat ourselves on the back. Then a Twitter engineer would walk over and ask "does it scale to 50 million posts per day?". As of February 2010, that's how many tweets per day Twitter was handling. That is almost 600 tweets per second. I'm sure if I ran some queuing theory calculations with a Poisson distribution, I'd see a potential spike of 2000-3000. Believe me, our one-day, naive implementation with a rented Web Server and s MySQL database won't handle that. Scaling Web/Enterprise 2.0 applications is sort of like running the 100 meter dash - 14 year old kids can do it in just over 11 seconds and Usain Bolt's world record is 9.58 seconds. Those numbers are just a second and a half apart, but that may as well be a 1000 mile wide chasm. Elite sprinters will spend their careers trying to cross that 1.42 second gap.
So scale is hard, we know that at Axeda. While this site is chock full of functional goodness for you to explore and experiment with, keep this in mind: our transactions per second for our production customers blow those Twitter statistics out of the water. 600 per second and they have to limit the API rate? Let's just say our customers won't let us get away with that, so as hard as scaling is, we push forward even harder.
We love a challenge.
