Hacker News Reader

Creating an index on the posted_at time may be harder than it sounds, with "tens of thousands of tweets per second" and a distributed database. The "within a second" approach (ie. loosening up the constraint of ordre) sounds pretty briliant to me.

View on HN

But you don't need to index on time; you can sort on the client. This is what twitter clients already do, except they sort an integer instead of a datetime.

Remember: Twitter is nothing new. We have done massively distributed messaging since the 70s. It's called e-mail.

Because the APIs fetch recent tweets, the service needs an index on time.

Although it should be easy for client applications to sort on time instead of id, that's not what all applications do. Twitter chose not to break clients that sort on id.

You could just fake the id later. Why ruin your architecture because your users are lazy?

Except in email everyone has a separate mailbox. On twitter everyone's mailbox overlaps and there are an infinite number of possible public views of the tweets (searches, lists, etc.)

Reply on news.ycombinator.com