Evolution of Bilibili’s Backend Architecture: From Monolithic Go to BFF and a Unified API Gateway
This article chronicles Bilibili’s transition from a PHP monolith to a Go‑based bilizone monolith, its subsequent decomposition into microservices, the adoption of Backend‑for‑Frontend (BFF) layers, and the eventual consolidation into a unified API gateway that streamlines routing, security, and traffic management across the platform.
In 2015 Bilibili’s rapid growth exposed the limitations of its PHP monolith, prompting a rewrite in Go that produced the first Go project, bilizone, which consolidated chaotic PHP logic into a more standard Go application.
Although bilizone offered stable data structures, reliable interfaces, and effective monitoring, it remained a monolithic system, inheriting drawbacks such as high code complexity, tangled timeout settings, and costly testing and maintenance.
To mitigate these issues, Bilibili split bilizone into multiple independent business services (account, video, advertising, etc.) that exposed APIs directly via SLB, as illustrated in the accompanying diagram.
This direct exposure introduced new problems: tight client‑service coupling, excessive request counts, inconsistent protocols across departments, and duplicated cross‑cutting concerns like authentication and rate limiting.
The solution was to insert an app‑interface component, implementing the Backend‑for‑Frontend (BFF) pattern. The BFF aggregates data, provides coarse‑grained, client‑specific APIs, enables dynamic upgrades without protocol changes, and improves collaboration between mobile and gateway teams.
Early BFF implementations suffered from being a single point of failure; consequently, Bilibili evolved to a “vertical BFF” architecture (2016‑2019) with multiple BFF instances managed either by the gateway team or individual business teams, allowing clearer ownership and faster feature iteration.
Independent services such as live streaming (C++, PHP, Go), e‑commerce (Java/Spring), and dynamic content each faced their own stack challenges, leading to duplicated effort and increasing technical debt in cross‑cutting logic (security, logging, rate limiting).
Recognizing the need for a centralized solution, Bilibili introduced a unified API gateway that consolidates routing, authentication, rate limiting, circuit breaking, gray releases, traffic sampling, replay, and security controls, thereby decoupling services and standardizing operational practices.
commit 4ccb1497ca6d94cec0ea1b2555dd1859e6f4f223
Author: felixhao <g******[email protected]>
Date: Wed Jul 1 18:55:00 2015 +0800
project init
commit 6e338bc0ee638621e01918adb183747cf2a9e567
Author: 郝冠伟 <h*******@bilibili.com>
Date: Wed Jul 1 11:21:18 2015 +0800
readmeThe unified gateway not only streamlines traffic governance but also provides a standardized API development ecosystem, including domain planning, metadata platforms, precise documentation, type‑safe SDKs, and compatibility guarantees, with the project open‑sourced at https://github.com/go-kratos/gateway .
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
High Availability Architecture
Official account for High Availability Architecture.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.