Social Feed Platform

Topology Notes

• ·The post write path runs entirely through PostgreSQL + outbox + Kafka. The application writes post content and a corresponding outbox row in a single transaction. The outbox relay (CDC-based) publishes a post_created event to the fan-out Kafka topic. This ensures no post write is lost on application crash between the DB write and the Kafka publish: a critical correctness property for feed systems.
• ·Fan-out workers consume from the Kafka fan-out topic, read the follower list from PostgreSQL (via Redis cache-aside, TTL 60s), and write post IDs to each follower's Redis feed list using LPUSH + LTRIM to enforce the feed cap. Workers are stateless and scale horizontally: adding replicas increases fan-out throughput linearly until Redis write bandwidth becomes the ceiling.
• ·Redis stores feed data as sorted sets or lists keyed by user_id. Each feed entry is a post_id reference (8 bytes), not a full post payload. The feed read API fetches the post_id list from Redis, then bulk-fetches post payloads from PostgreSQL via read replica using a single IN query. This keeps Redis memory bounded while preserving sub-50ms feed read latency at scale.
• ·RabbitMQ carries notification fan-out events (new follower, post liked, comment received) as distinct exchanges from the feed fan-out path. Notification delivery is best-effort with dead-letter queue capture; feed fan-out is at-least-once with idempotent write design. These two fan-out paths must never share infrastructure : notification backlog must not delay feed fan-out.
• ·PostgreSQL read replicas serve two distinct read patterns: (1) social graph reads (follower lists, following lists) used by fan-out workers, and (2) post content reads (bulk post payload fetch) used by the feed read API. These should be separate replica instances or replica pools: fan-out worker read traffic is bursty and should not compete with user-facing feed read queries.