4 ms·
Right, but since Twitter manages all of Twitter's servers (and the dedicated low-latency network via which they're presumably all connected) they can satisfy bo
by dwineman 14y ago
Right, but since Twitter manages all of Twitter's servers (and the dedicated low-latency network via which they're presumably all connected) they can satisfy both of these constraints without sacrificing the third (immediacy). I'm speculating here, but I think that's why it takes a few seconds to post a tweet: it's propagating across the internal federation so that all the nodes have it before it "goes live."
- sp332 14y agoTo be specific, your tweet is not timestamped when you send it. It only gets an "official" timestamp when twitter decides to give it one, after receiving it. That means Twitter arbitrarily sets the timestamp whenever they get around to shoving it on top of your feed. So they do have the problem of tweets arriving out of order (due to network latency etc), they just hide it by rewriting timestamps! eta: I admit this is a smaller problem for a centralized service than a federated one, but I would argue that it can work "well enough".
- fleitz 14y agoHow is twitter immediate when it's down? Twitter doesn't solve the immediacy problem with any hard guarantees either. Most of the time email is on par with twitter.
- dwineman 14y agoHuh? When Twitter's down, no one can post, so immediacy is meaningless. This is like saying "my car's faster than yours after yours hits a tree."
- fleitz 14y agoExcept that twitter does go down, so if you had a distributed car that was incapable of hitting a tree it would be an advantage. The situ with email is that at any moment the system is up but individual nodes may be unreachable or delayed, conversely if twitter is up all nodes are reachable in constant time, but if it's down all nodes are unreachable. In real systems these two properties are mean virtually the same thing, at any given point in time your party may or may not be reachable with a given latency.