When the Estimate Changes the Design

// Proposal: build each home timeline at read time.
//   SELECT t.* FROM tweets t
//   JOIN follows f ON f.followee_id = t.author_id
//   WHERE f.follower_id = ? ORDER BY t.created_at DESC LIMIT 50

const timelineReadsPerSecond = 300_000;   // DDIA, Twitter 2012
const avgFollowsPerUser      = 200;       // rows on the left of the join

// Even with a perfect index, each read touches at least one row per followed
// account, then merges and sorts:
const rowsTouchedPerSecond = timelineReadsPerSecond * avgFollowsPerUser;
rowsTouchedPerSecond;   // 60,000,000 index entries per second

// Compare against a single node: a well-indexed server might sustain low
// hundreds of thousands of index lookups per second.
const perNode = 200_000;
Math.ceil(rowsTouchedPerSecond / perNode);   // ~300 nodes, doing only this

// Three hundred nodes to serve reads is not a tuning problem, and the shards
// make it worse: the follow set spans every shard, so each read fans out to
// all of them and its latency becomes the slowest one.
//
// Verdict: ruled out by two orders of magnitude. Pre-compute the timeline.

// Wide-column stores want partitions small - large ones concentrate reads,
// slow compaction, and cannot be split after the fact.
// Discord's key: (channel_id, bucket), bucket = a fixed 10-day window. They
// picked 10 days by checking their largest channels: at that width a bucket
// stayed comfortably under 100 MB, which was the target.

const busyChannel = { messagesPerDay: 500_000, bytesPerMessage: 1_000 };

// Keyed on channel_id alone, one partition grows forever:
const gbPerYear = (busyChannel.messagesPerDay * busyChannel.bytesPerMessage * 365) / 1e9;
gbPerYear;   // 182 GB in ONE partition - unmanageable

// Keyed on (channel_id, bucket) with a 10-day bucket:
const BUCKET_DAYS = 10;
const gbPerBucket =
  (busyChannel.messagesPerDay * busyChannel.bytesPerMessage * BUCKET_DAYS) / 1e9;
gbPerBucket;   // 5 GB - bounded, but ~50x the 100 MB target, so still too big

// So the bucket width is an output of the arithmetic, not a constant to copy.
// For a channel this busy, holding 100 MB means a bucket of hours:
const bucketDaysFor = (targetMB) =>
  (targetMB * 1e6) / (busyChannel.messagesPerDay * busyChannel.bytesPerMessage);
bucketDaysFor(100);   // 0.2 days, about 5 hours

// The cost of bucketing: a query spanning a quiet period must walk back
// through several buckets to collect 50 messages, so the read is no longer
// always a single partition hit - and the narrower the bucket, the more walks.
//
// And note what bucketing does NOT fix. Discord still hit hot partitions,
// because traffic across channels is wildly uneven: p99 historical reads of
// 40-125 ms on 177 Cassandra nodes, improving to 15 ms on 72 ScyllaDB nodes
// of 9 TB each. Bounding partition SIZE does not bound partition TRAFFIC.

// Proposal: recompute all recommendations nightly, in a 6-hour window.
const users = 80e6;
const bytesPerUserHistory = 50e3;
const windowHours = 6;

const totalTB = (users * bytesPerUserHistory) / 1e12;   // 4 TB to read
const requiredThroughputGBs = (totalTB * 1e12) / (windowHours * 3600) / 1e9;
requiredThroughputGBs;   // ~0.185 GB/s = 185 MB/s sustained, just to READ

// 185 MB/s of sequential reads is unremarkable for one NVMe device, so the IO
// is not the problem. The compute is:
const cpuMsPerUser = 40;
const coreSeconds = (users * cpuMsPerUser) / 1000;      // 3.2e6 core-seconds
const coresNeeded = coreSeconds / (windowHours * 3600); // ~148 cores

// 148 cores for 6 hours every night is real money and a hard deadline: lose
// two hours to a failure and the window is gone, with no room to retry.
// Worse, it does not scale with the business - double the users and either
// the window or the fleet doubles.
//
// The estimate does not say "impossible". It says the nightly batch has a
// cliff in it, and that an incremental design - recompute on activity, in a
// stream - has no window to miss. That is the decision the arithmetic forced.