4 ms·
For starters, I don't buy your premise that most mail doesn't go to dozens of recipients - I don't have data to back this up but I'd bet that between mailing li
by smanek 18y ago
For starters, I don't buy your premise that most mail doesn't go to dozens of recipients - I don't have data to back this up but I'd bet that between mailing lists, spam, etc., the vast majority of email (by volume) is sent to multiple recipient.
And yes, it is true that SMTP doesn't use polling. But that is because polling for messages doesn't scale very well - a smart 15 year old could tell you that. I don't how twitter's architecture works, but if it polls all a user's subscriptions each time that user logs in then I say that was a bad architecture decision.
It would be pretty straightforward to emulate subscriptions with a 'mailing list' type solution. The simple fact of the matter is that Twitter chose a poor architecture. If they simply used an inbox/mailing list type solution all their problems would be non-existent and twitter would scale, near linearly, as you increased the number of servers.
Yes, it would be grossly inefficient HD space wise - but who cares? Normalization (seems to be) what got them in this mess. And disk space is cheap enough that it doesn't really matter.
Assume Twitter had a million active users (they don't), and that they each sent 5 Tweets/day on average (users don't), and that each user was subscribed by 5 Users on average (they aren't). That means about 5GB of Tweets are made a day. Using an inbox type scheme (with absolutely no normalization - which is unlikely) that would only require about 25GB of storage a day. Given reasonable cluster costs (and assuming data is 4x redundantly stored on the cluster), that would require well under a $100K/year in storage expansion (to store all tweets forever). Using semi-intelligent caching and partial normalization I think it would be pretty easy to cut those storage requirements in half w/o breaking a sweat.
I say again Twitter's problems are trivial - they just seem to have (initially) made a lot of poor design choices, and are now living with the consequences.
- bluelu 18y agoI completely agree with you! (smanek)
- Tichy 18y agoI can't really defend Twitter's architecture, I am simply interested in the best way to implement something like that as well - but not as a centralized service. Just a note: email does polling, too. Most email clients poll the server on a regular basis. But that is usually every 5 minutes or less? Twitter has just limited polling to 30 times per minute for external clients, if I remember correctly. I haven't thought too deeply about it, but I wonder if a mixture between polling and pushing could work. Either it could be decided on the nature of the client if it should push or poll (ie how many subscribers does it have, how active is it), or clients could connect and say "please push for the next 20 minutes" or just send keep-alives. If client alive, push, otherwise let him poll? I doubt that polling could be eliminated completely. If an email server is offline for an extended period of time, the message never arrives. Mabye that is acceptable, though.