Evolution of Bilibili's API Gateway Architecture: From Monolithic to Microservices

This article chronicles the evolution of Bilibili's API gateway architecture from 2015 to the present, detailing the company's journey from monolithic PHP applications to sophisticated microservices with unified API gateways.

The narrative begins with Bilibili's early struggles in 2015 when the platform experienced frequent crashes due to PHP's limitations in handling growing traffic and complex business logic. The first major transition occurred when the company adopted Go to rebuild its core services, starting with the bilizone project - a monolithic application that, while more stable than its PHP predecessor, still suffered from high code complexity, single points of failure, and difficult maintenance.

The next evolutionary step involved breaking down the monolithic bilizone into multiple independent business applications (accounts, articles, advertising, etc.) that communicated directly with clients through SLB. However, this approach created new challenges including tight coupling between clients and services, multiple round-trip requests, protocol inconsistencies across departments, and duplicated cross-cutting concerns like authentication and rate limiting.

To address these issues, Bilibili introduced the BFF (Backend for Frontend) pattern with an app-interface component that acted as an intermediary between clients and backend services. The BFF pattern provided several advantages: lightweight interactions through protocol simplification and data aggregation, differentiated services with data trimming and terminal-specific APIs, dynamic upgrades without breaking client contracts, and improved communication efficiency through specialized mobile business and gateway teams.

As the business grew, the BFF architecture evolved into multiple vertical BFF instances, each handling specific business domains. This period (2016-2019) saw the emergence of specialized teams for main site services, e-commerce, live streaming, and dynamic content. However, this distributed approach led to increased complexity, communication overhead between teams, and duplicated cross-cutting concerns across multiple BFF instances.

The solution was the introduction of a unified API gateway that centralized routing, authentication, rate limiting, and security features. This unified gateway enabled decoupled development, allowed teams to independently develop and deliver microservices, and separated business logic from cross-cutting concerns. The unified gateway provided advanced features including full-link gray release, traffic sampling and replay, and traffic security control.

The current architecture represents the culmination of years of evolution, featuring a standard internal API gateway that incorporates best practices from previous implementations. This gateway serves as the foundation for a comprehensive API governance ecosystem including API domain planning, standardized metadata platforms, precise documentation and debugging tools, type-safe SDK generation, and API compatibility assurance services.

The article concludes by emphasizing that API gateway development is not just about building infrastructure but creating a complete API development ecosystem that improves developer experience and ensures service quality. The gateway is developed as open-source software, inviting community feedback and contributions.