Designing a Scalable Feed Stream System Architecture

Feed‑stream systems deliver continuously updated content (e.g., posts, videos, messages) to users based on follow relationships, and are the backbone of popular mobile products such as Weibo, WeChat Moments, TikTok, and Toutiao.

Data classification : publisher data, follow relationships (single‑direction or bi‑directional), and receiver data with time‑heat attributes. These map to three storage components: a permanent repository for publisher data, a follow table for relationships, and a sync store for recent receiver data.

Product definition : identify the feed type (micro‑blog, moments, short‑video, private messaging) and consider user scale, follow model, and ordering (time‑based vs. recommendation‑based).

Storage selection : for small scale, MySQL may suffice; for large‑scale or cloud‑native deployments, distributed NoSQL solutions such as Alibaba Cloud Tablestore or Bigtable are recommended for reliability, horizontal scalability, and multi‑copy durability.

Synchronization modes : push (write‑expansion), pull (read‑expansion), and hybrid push‑pull. Push is preferred for bi‑directional or small‑scale single‑direction feeds; hybrid is advised when a single‑direction feed exceeds ~10 million users; pull‑only is discouraged.

Metadata services : user profile tables, follow/friend tables, and an in‑memory session pool for online user tracking. Persistent storage of session data is optional for failover.

Additional features : comment and like tables follow the same storage pattern; search can be implemented via a search engine or full‑text capable databases; sorting is typically time‑based for follow‑driven feeds, while recommendation‑driven feeds require a different architecture.

Deletion and updates : delete content directly from the repository or mark it logically; versioned stores (e.g., Tablestore) support edit histories.

Overall architecture : two viable approaches—an all‑in‑one Tablestore solution or a composite of open‑source components (MySQL, Redis, HBase) each handling specific responsibilities. The choice depends on team expertise, operational preferences, and cost considerations.

The article concludes with brief outlines for specific feed types (moments, micro‑blog, short‑video, private messaging) and points readers to further detailed design posts.