Designing a Scalable Feed Stream System Architecture

The mobile‑first era has popularized feed‑stream products like WeChat Moments, Weibo, and TikTok, where information units (feeds) are continuously pushed to users based on follow relationships.

A feed‑stream system can be viewed as a data flow that transports N publishers' feed items to M receivers through follow graphs, requiring three data categories: publisher data, follow relationships, and receiver data ordered by time or relevance.

Key design dimensions include user scale (from ten‑thousands to billions), relationship type (single‑directional follows vs. bidirectional friendships), and ordering strategy (pure time‑line vs. recommendation scores). These factors drive storage and subsystem choices.

Storage must guarantee durability, support efficient retrieval of a user's own posts, and scale horizontally. For small to medium workloads MySQL may suffice, but for billion‑scale systems distributed NoSQL stores such as Tablestore or Bigtable are recommended due to higher write throughput and automatic sharding.

Synchronization can follow three patterns: push (write‑expansion), pull (read‑expansion), or a hybrid push‑pull model. Push is preferred for bidirectional relationships, pull is viable for low‑scale single‑directional feeds, while the hybrid approach balances resource usage for large‑scale single‑directional feeds with big influencers.

Metadata services store user profiles, follow/friend lists, and online session pools; they can be implemented with the same NoSQL or relational databases used for the main store, often kept in memory with persistence for failover.

Additional features such as comments and likes share the same storage principles as feeds and are best kept in distributed NoSQL tables to avoid complex transactions.

Search functionality for users, feed content, or comments can be achieved by either integrating a dedicated search engine or leveraging full‑text capabilities of modern databases; the choice depends on existing infrastructure.

Ordering is currently based on timestamps for classic social feeds, while recommendation‑based ordering requires a different architecture and is not covered here.

Deletion and update of feed items are handled by removing or versioning entries in the storage layer, ensuring compliance with legal requirements for rapid content removal.

In summary, a scalable feed‑stream system can be built either with a single cloud‑native NoSQL service (e.g., Tablestore) or with a combination of open‑source components (MySQL, Redis, HBase), each fitting different team preferences and operational constraints.