Trade-offs & Decisions

When a post is created, immediately distribute it to every follower's pre-built feed. Feed retrieval becomes a bounded lookup independent of the number of accounts the reader follows. Write cost scales with follower count. A strong default for a read-heavy platform with a normal follower distribution.

When a user requests their feed, fetch recent posts from all followed accounts on the fly. Read cost scales with the number of accounts followed; write cost stays low. A reasonable choice when posts are rare relative to reads, or when an account's follower count makes write-time fanout impractical.

Use fanout-on-write below a configurable follower/activity threshold and fanout-on-read above it. The Feed Service merges both sources. For the workload assumed in this design, this gives good behavior across the full follower distribution, at the cost of more implementation and operational complexity than either pure strategy alone.

Cheap per-byte storage with effectively unbounded horizontal scalability. A CDN serves cached bytes for the large majority of requests after the first, reducing — not eliminating — origin load and cost. No application-server capacity is consumed serving binary blobs.

Expensive per-byte. Finite scalability. Every unique request hits your infrastructure. Application servers blocked on file I/O instead of business logic.

Client → application/upload server → object storage. Simple to reason about and easy to add inline validation, but ties fixed application-server compute and bandwidth directly to raw upload throughput.

Client → authorized temporary target → object storage, as covered in Media Upload Architecture. Removes the application tier from the bandwidth path entirely, at the cost of additional upload-state coordination — the system must track authorization, completion, and validation as separate steps rather than a single request.

A simpler state model — a post is either fully processed or the upload failed — but upload latency includes the full cost of resizing or transcoding, which can be seconds for images and much longer for video.

Faster acknowledgement to the client and independently scalable processing workers (see Media Processing Pipeline), at the cost of an explicit processing state machine, retry handling, and a window where the post exists but its media is temporarily unavailable.

Reduces hydration work at read time since the data is already sitting in the feed store, but creates enormous duplication across millions of followers' feed stores and a hard propagation problem: every edit or deletion now has to be re-applied to every copy.

Compact feed-store entries that preserve a single, centralized source of truth for post content (see Data Ownership & Storage Model). Requires a hydration step at read time to turn IDs into displayable posts, but keeps deletion, editing, and visibility changes correct by construction — there is only one place the truth lives.

Simple, predictable, and easy to explain: cross a configurable number of followers, become high-fanout. Easy to reason about in an interview or a first implementation, but ignores posting frequency, active-follower ratio, and current system pressure.

Incorporates follower count, posting frequency, active followers, queue pressure, and observed fanout cost (see Hybrid Fanout Strategy) to classify authors more precisely, at the cost of a more complex, less predictable classification system to build and operate.

Simple and familiar, but breaks down against a feed that keeps changing underneath the reader: new posts shift what would have been at a given offset, ranking changes move items between pages, and readers can see duplicates or missed posts across page boundaries.

Each page carries an opaque cursor describing where the next page should continue from (see Feed Pagination). For a chronological feed the cursor can be as simple as (timestamp, post_id). For a ranked feed, the cursor may instead reference a materialized or snapshotted result rather than only a timestamp, since ranking does not correspond to one fixed sort key.