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 through. 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 not... -josh 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.
