Evolution of Bilibili Dynamic Feed Architecture: From Incremental Pull to Push-Pull Hybrid

Business Overview

Bilibili's dynamic feature allows users to share text, images, videos, and other content, enabling interaction between regular users and creators (UPs). It supports short dynamic videos (under 15 seconds) and serves as a major traffic source with billions of daily page views.

Business Characteristics

Huge traffic pool: daily page views exceed one billion.

Complex functionality: around 30 types of dynamic cards, requiring deep business logic understanding.

Broad coverage: over 20 non‑dynamic services interact, creating a mesh of inter‑dependent components.

Strong traffic diversion: dynamic content drives nearly a hundred million daily clicks.

Long iteration history: launched in September 2017, now over five years old.

Architecture Overview

The system follows a four‑layer content workflow: production, pre‑processing, persistence, and indexing. It adopts a typical microservice layered architecture with a BFF‑style dynamic gateway that separates rendering and layout logic from the core services.

The motivation for this redesign was the inability of the original C/S architecture to provide a consistent experience across mobile, web, PC, and OTT clients, each with distinct customization needs.

Storage Design

User list caching stores only dynamic IDs with sentinel values (dyn_max, dyn_zero) to prevent cache penetration and indicate full cache coverage. Feed caching retains only the most recent items to achieve hot‑cold data separation.

Database design separates account/behavior storage, indexes from content, uses relational databases with sharding for dynamic content, and KV stores for high‑write scenarios.

Architecture Evolution

Stage 1 – Incremental Pull : Initially, the feed used a pull model fetching followers' outbox data, leading to read amplification and inbox gaps when users missed updates.

Stage 2 – Asynchronous Inbox Construction : Introduced Kafka‑driven incremental writes to the inbox, but faced issues like inbox gaps, message loss, and high outbox pressure.

Stage 3 – Pure Pull Mode : Switched to a pure pull approach where the client requests pages based on the maximum dynamic ID, with red‑dot caching to mitigate read amplification.

Stage 4 – Push‑Pull Hybrid : After completing full‑fan‑list construction, a hybrid model was adopted: large UPs use pull, small UPs use push; active users receive push updates, while inactive users remain pull‑based. This reduces outbox pressure and improves tail latency.

The final design includes modules for list merging, inbox storage, push processing, and relationship‑chain compensation.

Future Development

Plans include further platformization of image‑text content, deprecating legacy features, extending the platform to more scenarios, and optimizing feed cost and relevance through interest‑based recommendations.

Conclusion

The hybrid push‑pull architecture resolves previous feed gaps, improves scalability, and provides a more maintainable and resilient system for Bilibili's dynamic feed.