Hi Taylor (et al.),

There are two reasons to think that, with the scheme you propose,
tweet ids will not necessarily be monotonically increasing.

Naveen hit the first:

> It seems if two messages are posted at very close to same time, they may not
> be sequential since the bottom bits will be randomly generated

There is another: Time synchronization is hard to always get right
(Einstein jokes aside). Clock skew happens for any number of reasons
-- sometimes ntpd sends time backwards when network i/o gets really
ugly, machine clocks wander, colos get out of sync, humans err, etc.
These are rare events, but they do happen, and they can cause
misalignment of clocks big enough for the odd tweet or two to fall

Does missing the odd tweet or two matter? As for the tweet themselves:
Probably not. But if it gets noticed, it causes users / developers to
lose some amount of trust in their app / platform...and that matters a
lot and can also generate a lot of annoying support emails.

You wrote:

> since_id will work as well as it does today as a result of this change.

Is that assuming monotonically increasing tweet ids? If not, would you
mind elaborating?

Having a universal counter is untenable, but having occasional,
undiagnosable, unreproducible glitches also sucks. :) Thinking out
loud, perhaps there is some middle ground -- a way to have generally
monotonically increasing ids globally, and guaranteed monotonically
increasing ids along some useful dimension, such as per user (this
doesn't play nicely e.g. w/ Cassandra, but it is still reasonably
scalable by other means). Not sure whether that would help folks or


To unsubscribe from this group, send email to 
twitter-development-talk+unsubscribegooglegroups.com or reply to this email 
with the words "REMOVE ME" as the subject.

Reply via email to