|
The problem with scaling Twitter is not the choice of framework, but the choice of architecture. In other words, abandoning Ruby On Rails probably isn't going to solve all of their problems. At the same time, I'm not sure that decentralization is necessary and comes with its own set of challenges. The real problem is that the polling model of the Twitter API doesn't scale for real-time communications. As it is today, many Twitter clients will poll (by default) every 3-5 minutes to see if there was an update. Not only are they not really participating in real-time, they are generating an enormous number of requests that - even while each payload is small - generate a lot of overhead in aggregate just in checking and responding. As I've suggested in the past , a better solution would be to move the "real-time" API around the Jabber/XMPP client instead of HTTP. The good news is that Twitter already has an IM presence so it's easy enough for third-party clients...
|