Problem Statement: A Write-Heavy, Read-Amplified Activity Feed
Frames the activity stream as an event capture, fanout, and ranked-read pipeline rather than a simple chronological log.
Problem statement
Design an activity stream for a social application that captures user actions — following, liking, posting, commenting, sharing, checking in — and turns them into a chronological or ranked feed that other users consume. This is the primitive behind the Facebook News Feed, the Twitter home timeline, the Instagram feed, and the LinkedIn activity feed.
An activity is best modeled with the W3C Activity Streams vocabulary: an actor performs a verb on an object, optionally toward a target. "Alice (actor) liked (verb) Bob's photo (object) in the Vacation album (target)." Every downstream decision — storage, fanout, grouping, ranking, privacy — flows from treating these as immutable, append-only events.
Why this problem is hard
A naive design writes one row per activity and reads them back in order. That collapses the moment you add two facts: writes amplify and reads amplify. When a user with 40 million followers posts, that single event must eventually influence 40 million feeds. When a reader opens the app, they expect the 20 most relevant activities from everyone they follow, merged, grouped, filtered, and ranked, in under 100 ms.
The attached brief requires capturing events from many action types, storing chronological history, serving a personalized or global feed, grouping similar actions, high-throughput ingestion, near-real-time updates, scale for large user bases, and filtering by action type. The section rhythm, visual vocabulary, multi-cloud diagrams, and quiz placement follow the uploaded orchestrator and master prompt. Field shapes follow the uploaded course profile and gold standard.
Public operating baseline versus design assumptions
Public figures establish that this category is operationally real. Twitter reports roughly 500 million posts per day, an average of about 5,800 posts/sec, with a recorded peak of 143,199 posts/sec. Instagram reported 95 million photos and videos shared per day and 4.2 billion likes per day. Facebook's TAO graph store paper reports over one billion reads per second at peak. LinkedIn reports serving its feed to roughly one billion members. These are cited company figures, context only — not our design targets.
For capacity planning this answer explicitly assumes a mature mid-size network: 200 million MAU, 60 million DAU, 8 million peak concurrent, 2 billion raw activity events per day, and a 4x event peak. Unless a number is tied to a citation, it is a stated design assumption.
The four architectural planes
- Capture plane: clients and services emit validated, idempotent activity events into a durable log (Kafka).
- Processing plane: stream jobs enrich, group, aggregate, and fan events out to per-user or per-audience stores.
- Serving plane: feed APIs merge pushed inbox entries with pulled celebrity content, rank them, and paginate.
- Learning plane: telemetry, engagement signals, and ranking feedback loop back into models and policy.
A strong answer keeps these planes separate. It lets the serving plane degrade without losing events, and lets the learning plane improve ranking without rewriting the immutable event log.
Key Highlights
- •Model every action as an immutable Activity Streams event: actor, verb, object, target.
- •The two forces that shape the design are write amplification (fanout) and read amplification (merge + rank).
- •Public figures provide context; every uncited scale or SLO in this answer is an explicit design assumption.
- •The architecture has four planes: capture, processing, serving, and learning.
- •A feed read must stay fast even when the underlying event volume is enormous.
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "I will separate event capture from feed serving, because they have very different consistency and latency needs."
- "Before choosing storage, let me define which reads are pushed, which are pulled, and which are merged."