Draft coverage
This scenario is in the knowledge catalog, but its derived intelligence is not fully modeled yet. Topology relationships are missing. Advisor strengths are not authored. Treat the reference content as useful background, not a complete architecture review.
Summary
A social activity feed architecture where user actions (posts, likes, comments, follows) fan out asynchronously to follower timelines. Redis stores hot feed data as pre-materialized lists per user, enabling O(1) timeline reads for the 99th percentile of users. Kafka carries fan-out work to async workers that write to follower Redis keys. PostgreSQL is the durable store for the social graph, posts, and user content. The system uses a hybrid fan-out model: fan-out-on-write for users with fewer than ~10,000 followers (low fan-out cost), fan-out-on-read for high-follower celebrity accounts where pre-materialized fan-out would saturate workers and Redis write bandwidth.
Problem Statement
Social feed platforms have an extreme read/write asymmetry: most users read their feed far more often than they post, but a single post from a high-follower account may require writing to millions of follower feed lists simultaneously. Synchronous fan-out on write is acceptable when follower counts are bounded, but breaks under celebrity accounts where a single post triggers 10–50 million Redis writes. The result is fan-out amplification: the write cost of one action grows with the fame of the actor, not the frequency of the action. The architecture must prevent celebrity posts from becoming an operational incident while keeping feed read latency under 50ms p99 for all users at any traffic level.
Complexity
high
Maturity
Experienced Backend Team
Patterns
6 patterns
Modeling
draft