There has been a lot of talk in the last couple days about the decentralization of Twitter. What? A few top bloggers got annoyed that Twitter keeps going down during peak use and here we are. Lame.
Back when Twitter first launched, my boss couldn’t say enough praise for their use of Ruby on Rails and the rapid speed of their development. I agreed that the speed at which they brought their service to life was impressive, but I wasn’t sold on Ruby. Rightfully so, as I soon was pointing out Twitter’s scaling problems and their blaming Ruby (it wasn’t Ruby, but it certainly cast doubt).
There are performance issues with Twitter. Their dev team blamed Ruby and was ultimately wrong. The product is so addictive that folks get angry when they can’t have it. So why not split this product up and decentralize it? Let’s make it a system of RSS feeds and all subscribe to the feeds we want. Why not?
Remember that Twitter is a service. Consider it somewhat like AIM or LinkedIn. Users have an identity, profiles, etc. It’s a social network. A very popular one at that. And decentralizing Twitter means creating a decentralized social network.
The value of Twitter (and why it wouldn’t succeed in a decentralized environment):
- Unique identity of each individual user.
- Speed of text messages and group announcements.
- Twitter Timeline… You can see a river of everyone’s posts.
If Twitter were switched to a system of RSS feeds we’d be nowhere further than the present blog feeds. A one-to-many approach instead of many-to-many. It would simply be a restriction and/or self-imposed limit to 140 characters + a topic that we’d be living by.
Prognosis: Twitter will step up and solve this with architectural improvements and bandwidth/load/communication concentration. If they don’t already have request concentration which directs requests to the appropriate cluster and DB, they’re already working on building it. The discussion of decentralization will go away.