Status ids are currently strictly increasing -- that means they're globally
unique. In the future, they will be generally increasing -- but still
globally unique.

We'll be generating these unique ids in a fault-tolerant, highly-available,
low-latency, and high-throughput service. If solving these sorts of
challenges, and they aren't always easy, interest you:
http://twitter.com/job.html?jvi=oAPbVfwf,Job

-John Kalucki
http://twitter.com/jkalucki
Infrastructure, Twitter Inc.


On Wed, Feb 17, 2010 at 11:16 PM, Quy <quyten...@gmail.com> wrote:

> Hi John,
>
> Does that mean that status_ids may not be unique across all users? For
> example, one user could have status_id of 123 and another user can
> have status_id of 123 so you have to uniquely identify them by their
> user/status_id combination?
>
> On Feb 11, 11:40 pm, John Kalucki <j...@twitter.com> wrote:
> > In short, today, yes. Soon, no, but it might not matter.
> >
> > At the moment, status ids are strictly increasing. We can't keep
> generating
> > status ids from a single critical section forever though -- at some point
> > soon we'll have a loosely-coupled distributed id generation system and
> ids
> > will be k-sorted. Perhaps the most significant bits will be monotonically
> > increasing and the remainder of the precision will be opaque, and appear
> > random. With any luck, the monotonically increasing precision will map,
> > roughly, to time at a second resolution, so that the k-sorting will be
> > within a second quantum. This would allow collation order based on the 1
> > second created_at and a collation order based on the most significant
> bits
> > will produce a similar, but not identical, ordering. Largely speculation.
> >
> > So, in the end, the date field remains the safest and the most
> future-proof
> > way to sort statuses.
> >
> > -John Kaluckihttp://twitter.com/jkalucki
> > Infrastructure, Twitter Inc.
> >
> > On Thu, Feb 11, 2010 at 2:36 AM, Quy <quyten...@gmail.com> wrote:
> > > When I am sorting tweets, can I just do a simple sort DESC on
> > > status_id instead of the creation date? I assume status_ids are
> > > created sequentially going up so sorting on status_id would be more
> > > efficient than trying to sort on the created_at field.
>

Reply via email to