Social-feed cases: design and defend a feed-backed app

Produce a complete design doc for a social app (a short-form posting app with a home feed, push/email notifications, and presence), making and justifying the fan-out, hybrid, delivery, and ordering decisions from the unit — then build a small prototype that empirically validates your celebrity fan-out strategy and your at-least-once-with-dedup notification path.

• Write a one-paragraph brief with explicit input assumptions: total users, daily active users, average and tail (celebrity) follower counts, posts/user/day, feed opens/user/day, and notifications/user/day. State every assumption.
• Estimate the load: average and peak feed-read QPS, post-write QPS, and notification QPS (requests/day ÷ ~10^5, with a justified peak multiplier), each rounded to one significant figure. Derive the read:write ratio and use it to justify the default fan-out strategy.
• Specify the feed: choose fan-out-on-write as the default and define the celebrity threshold (the follower count above which an author is pulled at read time), with the arithmetic showing why pure push fails at the tail. Describe the feed cache (post ids, capped, per-user) and cursor pagination.
• Specify notifications: the async fan-out pipeline, per-channel queues, the idempotency key, retry with backoff+jitter feeding a DLQ, and the priority lane that keeps transactional sends ahead of bulk. State the delivery guarantee (at-least-once + dedup) and why exactly-once is not on the table.
• Specify ordering and consistency: per-conversation/per-feed sequence or timestamp strategy, which surfaces are eventually consistent (feed, presence, read receipts) and which need stronger guarantees, and why that staleness is acceptable.
• Write the architecture decisions as a short list, each justified by a specific number ('celebrity threshold = 1M followers, because a push above that exceeds the X writes/min the feed store sustains').
• Build a prototype (any language): a publisher that fans out posts to follower feeds with a configurable celebrity threshold (push below it, pull above it), and a notification sender with a retry+DLQ path and an idempotency store.
• Validate the celebrity hybrid: measure feed-write volume and read-assembly cost as you vary the threshold and inject a high-follower author, showing the write storm under pure push and its disappearance under the hybrid.
• Validate delivery: inject provider failures and a backlog re-flush, and show that the idempotency key collapses duplicates to one delivery while the DLQ captures permanently-failed sends.

• A design doc readable in a few minutes: load estimates (avg + peak, one significant figure), the read:write ratio, and the fan-out/hybrid/delivery/ordering decisions, each citing the number that drives it.
• An explicit celebrity threshold with the arithmetic that sets it, plus the feed-cache and pagination design.
• A working prototype whose measurements show the celebrity write storm under pure push and its removal under the hybrid, with the threshold and follower counts that produced each.
• A delivery demonstration: a fault-injection run where duplicates are collapsed by the idempotency key and permanently-failed sends land in the DLQ, with the before/after duplicate counts.
• A short write-up: one paragraph on what the estimate revealed before any code, and one on where the prototype's behavior differed from the napkin and why.