3 ms·
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 se
by petervandijck 16y ago
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.
- jrockway 16y agoBut 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.
- frognibble 16y agoBecause 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.
- jrockway 16y agoYou could just fake the id later. Why ruin your architecture because your users are lazy?
- deleted 16y ago[deleted]
- kingryan 16y agoExcept 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.)