Twitter: Don’t blame Ruby, blame Scoble

Micro-messaging site Twitter has gone from zero to transparent in a hurry. That is to say, it has gone from keeping users in the dark during its downtime to explaining the problems it is having in detail. Tonight, developer Alex Payne wrote a Q&A post on the Twitter Developer Blog in which he answered some users’ questions about Twitter’s recent woes.

One particularly interesting question was the following:

charles asks if there’s anything users can do to lighten our load.

To which Payne responded:

The events that hit our system the hardest are generally when “popular” users – that is, users with large numbers of followers and people they’re following – perform a number of actions in rapid succession. This usually results in a number of big queries that pile up in our database(s). Not running scripts to follow thousands of users at a time would be a help, but that’s behavior we have to limit on our side.

Most users of Twitter will single out one person who this points to: blogger and Fast Company employee Robert Scoble.

Scoble, with his 25,000+ followers and 21,000+ people he is following is a beast on the service. I would consider myself a fairly heavy user of the service and I’ve sent 3,598 tweets (Twitter messages) — Scoble has sent 12,318. This is clearly putting a strain on the service.

Perhaps more interesting was that in multiple responses, Payne more or less said not to blame Ruby on Rails (RoR) for Twitter’s woes. A lot of commenters on this blog and others are quick to jump on and blame RoR, which has even led to rumors that Twitter was abandoning it. These turned out not to be true, and in fact Twitter will continue to use RoR for the time being — at least for its front end work.

Payne also said he would use Rails again if he were looking for rapid prototyping, as Twitter was. (Payne was not around however during the initial building of Twitter.) That idea is in line with a post Nati Shalom, GigaSpaces’ chief technology officer, wrote earlier this month detailing his thoughts on Twitter’s problems from a back-end perspective.

I had a chance to talk with Shalom today about his post and his thoughts on Twitter’s woes. He believes the problem lies in the explicit contradiction between scaling and time to market. It’s also a problem with not knowing if a company will be successful and as such being cautious with spending money and time upfront to build something slowly that is fully scalable.

Shalom fully understands the burden the Twitter team now has. It basically has to take its first architecture, which isn’t working, and re-build it on the fly while the service is still running.

While exploring the issue for his own knowledge, Shalom noted Twitter’s unique position as a web application. It is neither solely a messaging app or a social networking app, but a combination of both. In the past companies had been able to build applications based on one of those foundations, but not both.

In some ways, Shalom finds it similar to the business-to-business (B2B) model that was exploding on the Internet in 2000. However this is even more complicated because with Twitter when you send out a message, you don’t know who is going to respond — it could be anyone.

Shalom agrees that all of the Ruby on Rails hatred in the blogosphere is misguided. That framework should still be fine for the front-end (just as Payne indicates), but it’s the site’s architecture or “engine” that needs to be rebuilt.

He notes that an OpenSpace community member he’s been in contact with claims that they can put a Twitter interface on top of GigaSpaces‘ own application servers to build a completely scalable version of the service. While the person claims to have a prototype working, it won’t be ready to show off until sometime this summer.

One thing is for certain with all of Twitter’s recent issues. A lot of start-ups in the future are going to learn from mistakes made. Today’s post follows Payne’s post last week stating that Twitter wasn’t built to handle its current usage.

While the core team that built Twitter at the time may have had no way of foreseeing today’s issues, companies in the future should learn from this and choose the correct architecture while taking the time to think about scalability, just in case they do hit it big.

You can find me on Twitter here along with fellow VentureBeat writers Eric Eldon, Dean Takahashi, Anthony Ha and Chris Morrison. Oh, and we have a VentureBeat account (for our posts) as well.

[photo: flickr/david sifry]