Apache bRPC
OrchestrationbRPC is an industrial-grade RPC framework written in C++, originally developed inside Baidu (as "baidu-rpc") to handle massive internal traffic across search, ads, and infrastructure services.
What it is
bRPC is an industrial-grade RPC framework written in C++, originally developed inside Baidu (as "baidu-rpc") to handle massive internal traffic across search, ads, and infrastructure services. It was open-sourced and later donated to the Apache Incubator, where it graduated as an Apache top-level project. It supports multiple protocols (baidu_std, Protobuf-based RPC, HTTP/HTTPS, hulu-pbrpc, sofa-pbrpc, public_pbrpc, Redis, Memcached, and more) over a single unified programming model, with built-in support for streaming, connection multiplexing, and a strong focus on low-latency, high-throughput services.
Note on category: the "Orchestration & Management" label here is misleading — bRPC is not a Kubernetes-native orchestrator or control-plane tool. It's a network communication framework you'd embed inside services that then get orchestrated by something else (K8s, Mesos, internal schedulers). If you're evaluating it as an orchestration layer, you're looking at the wrong tool.
Who builds it and why
Originated at Baidu, where it still handles a large share of internal RPC traffic across search and ads infrastructure — this is battle-tested at extreme scale, not a toy project. Development has broadened since Apache incubation: 323 contributors is a healthy, non-single-vendor number for a systems-level C++ project, suggesting adoption beyond Baidu into other Chinese tech companies (common in gaming, ad-tech, and fintech backends where bRPC's low-latency profile matters). The motivation is straightforward: build an RPC layer that performs under extreme QPS with predictable tail latency, without the overhead of gRPC's more general-purpose design.
Production readiness signal
17,550 GitHub stars and a commit as recent as 2026-07-01 (per the data provided) indicate active maintenance, not an abandoned artifact. Latest release 1.17.0 suggests a mature, incrementally-versioned project rather than one still finding its API. Apache-2.0 licensing is standard and unencumbered. CNCF maturity level is not publicly available — this is not a CNCF project, so don't expect CNCF-style governance ceremony (TOC sponsorship, security audits cadence, etc.) around it; it operates under Apache Software Foundation governance instead, which has its own rigor but different transparency defaults. Founding date isn't publicly documented, which is a minor gap for due diligence but not disqualifying given the visible commit and contributor history.
Who should use this
Teams running high-QPS, latency-sensitive C++ services — especially if you're already operating at a scale where gRPC's overhead (HTTP/2 framing, generic serialization paths) becomes a measurable tax. If your engineering culture skews toward Baidu-style infrastructure (large internal service meshes, heavy Protobuf usage, need for protocol flexibility in one binary), bRPC is a proven fit. Also relevant if you need built-in support for legacy protocols (sofa-pbrpc, hulu-pbrpc) during a migration.
Who should NOT use this
Skip it if your team is primarily Go, Java, or polyglot-microservices-first — bRPC's ecosystem, docs, and community support are heavily C++-centric and much of the documentation and community discussion is in Chinese, which is a real friction point for non-Chinese-speaking teams. Skip it if you want gRPC's broader multi-language client ecosystem and Cloud Native tooling integration (Envoy, service mesh sidecars are built around gRPC/HTTP semantics, not bRPC's protocols). Skip it if you're looking for a Kubernetes orchestration or management tool — again, this is a wire-level RPC library, not a control plane. And skip it if you need CNCF governance guarantees for procurement/compliance reasons, since this isn't a CNCF project.
Alternatives
- gRPC — the default choice for polyglot microservices, broader ecosystem, native Kubernetes/service-mesh tooling support.
- Apache Thrift — similar multi-protocol RPC ambitions, broader language support, less focused on extreme-scale C++ performance.
- Cap'n Proto (with its RPC layer) — for teams wanting zero-copy serialization performance without Protobuf's overhead.
Pricing
Fully open source under Apache-2.0. No paid tier, no commercial vendor behind it — you self-host, self-support, and rely on community/contributor activity for fixes and features.