1 TB
the last 7 days, in RAM, per copy
7 × 500M posts = 3.5B, at ≈ 300 B each, in 20 partitions of ≈ 52 GB. More than ten years, 600 billion posts, sit on SSD.
Tweets once took ≈ 15 s to be searchable, stuck behind slow fields and a sort buffer.
The 1-second fix
Index now, patch slow fields later. Derive doc IDs from creation time, so late posts slot in.
“#diwali” matches 3.5M posts per partition. Latest reads a handful.
Postings are read newest-first, so Latest stops after 20 hits. Top scores the newest 2,000 matches plus a small index of popular posts.
Likes change every second. Where do counts live?
Bad: Re-index on every like
200,000 deletes and re-inserts a second, into segments meant to freeze.
Good: Counters, updated in place
Sum 5-second windows; overwrite fixed-width columns. Postings never move.
Nobody sees a post they shouldn’t. Three layers, cheap to exact:
- Partition: audience terms, Bloom filters, tombstones
- Root: an exact check on about 60 finalists
- Hydration: drop any post deleted a moment ago
Assume 40,000 fans a second search “ind vs aus”
The postings cope; 800,000 identical partition calls a second don’t. Normalise to ≈ 10 keys, cache public results for 1 s, coalesce misses, personalise after.
Five new posts arrive while you scroll. Page 2 repeats five.
A max_id cursor marks a position in time, not in a list: “the 20 newest below this ID”. New posts wait above.
Remember
Stream posts into time-ordered partitions, searchable in a second. Latest stops early; Top scores a recent window with in-place counts. Filter cheaply, check exactly, collapse hot queries.