DBRaven
Event-Driven System

Social Feed Platform

high

Experienced Backend Team

6Decision

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.

social_feedfan_outevent_drivenrediskafkapostgresqlrabbitmqcelebrity_accountshybrid_fan_outtimeline
Evidence: Strong (82%)67 nodes73 relationships

Complexity

high

Maturity

Experienced Backend Team

Patterns

6 patterns

Modeling

draft