-
Website
http://www.scripting.com/ -
Original page
http://www.scripting.com/stories/2009/05/13/lessonsFromTheChangesInTwi.html -
Subscribe
All Comments -
Community
-
Top Commenters
-
eas
55 comments · 4 points
-
AndrewBurton
134 comments · 10 points
-
Michael Markman (Mickeleh)
154 comments · 16 points
-
Rex Hammock
52 comments · 9 points
-
malatmals
81 comments · 3 points
-
-
Popular Threads
-
How I develop formats and protocols. (Scripting News)
1 day ago · 11 comments
-
Open is in the eye of the beholder. (Scripting News)
3 days ago · 13 comments
-
Store Twitter URLs in earth's oceans? (Scripting News)
5 days ago · 16 comments
-
Why today's Twitter is like Napster in Y2K. (Scripting News)
5 days ago · 15 comments
-
If you wrote the words you own the copyright. (Scripting News)
5 days ago · 7 comments
-
How I develop formats and protocols. (Scripting News)
So I started to think about the volumes of traffic that twitter has to cope with. A standard API call to get the latest updates for a user can be made up to 100 times per hour and returns the last 200 relevant tweets by default. A search can be made more times via the API but I not sure how many. In any case with the increase of client apps to interact with twitter and the increase of the number of users the number of API calls will be increasing dramatically. It is no wonder that they are looking for ways to cut down the work that the server is undertaking.
On the other hand this could just be disembling the real reason behind it all. Maybe they are looking for features that power users/communities will pay for and this maybe one.
- New setting
1) a reply is posted
2) retrieve original poster's followers
3) see if that @reply user is followed by those users
4) post the message to the necessary timelines
**Depending on their structure (!!) that can be a pretty easy query. i.e. if they can do some simple "set" queries to find friends of friends.
- Old setting
1) a reply is posted
2) retrieve original poster's followers
3) for each of those followers, see if they have the special setting enabled
3a) If so, populate the timeline
3b) If not, check if the @reply user is followed by that user
3a/3b are the killer - if the data isn't structured right, it becomes a much more complex problem to find the intersection of two settings than simply the friends of friends. This may not have been too much of a problem when the most popular person had 100,000 followers. But now that those numbers are nearing 2M, that's a lot of operations to perform for one tweet.
Heaven's forbid they have explained it THAT way instead of saying they took away the option because it confused people.
It seems to me, you just send the tweet to the cluster for each of the followers to be added to the timeline. That cluster can then check the receiving user's settings to determine if the tweet should be filtered out. Simple!
Because now, instead of performing the intersection of several in-memory arrays of numeric id's, you have to perform a round trip to the server for each of a user's followers to see if they have this setting enabled. Again - this is based completely on speculation of how the architecture is - that friends/followers are cached in memory and per-user settings are not. Even if the per-user settings are, I wouldn't think it'd be too easy to do a simple "join" as they're likely using a simple key/value memcache store. If they have fractured users into clusters, those clusters still have to do the work of checking each incoming tweet's followers to see if the "special setting" is enabled in order to determine whether to send the tweet or not. My guess(!!) is that the social graph data is heavily cached and even if the user settings were, it would still require iterating over a large number of users to get the setting.
Or... should companies make changes and then post explanations why?
http://entertainment.timesonline.co.uk/tol/arts...
Why couldn't the micro-blogging information flow through a distributed social network of nodes? Mobile open source P2P?