We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · API Design & Protocols
A high-performance RPC framework by Google using Protocol Buffers and HTTP/2. Much faster than REST for service-to-service communication.
In short
gRPC is an open-source remote procedure call framework from Google that lets one service call a function in another service over the network as if it were local. It serializes messages with Protocol Buffers and transports them over HTTP/2, which makes it faster and more compact than JSON-over-REST for service-to-service communication.
In short
gRPC is an open-source remote procedure call framework from Google that lets one service call a function in another service over the network as if it were local. It serializes messages with Protocol Buffers and transports them over HTTP/2, which makes it faster and more compact than JSON-over-REST for service-to-service communication.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers gRPC across a run of lessons, not one page. These 4 alone are about 86 minutes of step-by-step reading, every one with a quiz.
Google's high-performance RPC framework, binary protocols, HTTP/2 streaming, and auto-generated clients.
Apache Thrift is a cross-language RPC framework built at Facebook. Learn its IDL and code generation, and see how it compares with gRPC and Protobuf.
Google's language-neutral binary serialization, smaller, faster, and strictly typed.
Three thousand updates took 117 ms sent one at a time and 17 inside one CALL. A function that tries to COMMIT fails outright, and an EXCEPTION block inside a loop took 9 ms to 134 while catching nothing.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with gRPCpay once,
yours for life
gRPC stands for gRPC Remote Procedure Calls (the name is recursive, like GNU). It was built by Google in 2015 from an internal system called Stubby that already handled billions of calls per second across their data centers. The idea is simple: instead of building URLs, picking HTTP verbs, and parsing JSON, you just call a method like getUser(id) and gRPC handles moving the request and response across the wire.
You start by writing a .proto file that defines your service and its messages. A service lists the methods. A message lists the typed fields. From that single file, the gRPC compiler generates client and server code in over a dozen languages, so a Go server and a Java client agree on the exact shape of every message without anyone writing serialization code by hand.
This contract-first approach is the real selling point. The .proto file is the source of truth. Change a field and both sides regenerate, so a typo that would silently break a JSON API gets caught at compile time instead of in production.
Two technologies do the heavy lifting: Protocol Buffers and HTTP/2. Protocol Buffers (protobuf) is a binary serialization format. Instead of sending the field name user_id as text every time, it sends a small integer tag and the raw bytes of the value. A message that is 80 bytes as JSON might be 25 bytes as protobuf, and parsing it skips all the string scanning that JSON requires.
HTTP/2 is the transport. It multiplexes many calls over a single TCP connection, so hundreds of concurrent requests do not each need their own connection or wait in line behind each other. It also compresses headers and supports long-lived streams, which is what enables gRPC streaming.
gRPC supports four call types. Unary is the normal request-response. Server streaming sends one request and gets a stream of responses back, good for things like a feed of stock prices. Client streaming sends a stream of requests and gets one response, good for uploading chunks. Bidirectional streaming runs both directions at once over the same connection, which suits chat or live telemetry.
gRPC shines for internal service-to-service traffic inside your own infrastructure, especially in a microservices setup where one user request fans out to dozens of backend calls. The binary encoding, connection reuse, and code generation cut both latency and CPU compared to REST. Companies running large microservice fleets often see meaningful tail-latency improvements after switching internal calls to gRPC.
The main weakness is the browser. Browsers cannot speak raw gRPC because they do not expose the low-level HTTP/2 frame control gRPC needs, so a public-facing API for web apps usually still uses REST or GraphQL, or runs through a gRPC-Web proxy. gRPC is also harder to debug by hand. You cannot curl a binary protobuf endpoint and read the response, so you lean on tools like grpcurl or Postman's gRPC support.
Other trade-offs: the .proto contract adds a build step and a code-generation pipeline, and protobuf's strictness means you have to follow field-numbering and compatibility rules carefully when evolving schemas. For a small public API consumed by third parties, plain REST with JSON is often the more practical choice.
Picture an online store. The checkout service needs the current price for an item, the user's saved address, and a fraud score before it can place an order. Over REST that is three separate HTTP calls, each opening a connection, sending JSON headers, and parsing a JSON body.
With gRPC, the checkout service holds one persistent HTTP/2 connection to each backend and fires getPrice, getAddress, and getFraudScore as multiplexed calls in flight at the same time. Each message is a few dozen bytes of protobuf. The generated client code means the developer just writes pricingClient.getPrice(request) and gets back a typed Price object, no manual parsing.
If the catalog team later adds a currency field to the price message, they add it with a new field number that has never been used, regenerate, and old clients that do not know about the field simply ignore it. Nothing breaks, and the upgrade is backward compatible by design.
Built gRPC from its internal Stubby system and runs it across nearly all internal service communication in its data centers.
Netflix
Uses gRPC for inter-service calls in its microservices backend to cut latency and serialization overhead versus REST.
Kubernetes
Components and the container runtime interface (CRI) between the kubelet and runtimes like containerd communicate over gRPC.
Cloudflare
Adopted gRPC for internal control-plane and service-to-service APIs where high throughput and a strict schema matter.
For service-to-service calls, usually yes. Protocol Buffers produce smaller payloads than JSON and parse faster, and HTTP/2 reuses a single connection for many concurrent requests. The gap is widest under heavy internal traffic; for a single occasional call the difference is small.
Not directly. Browsers do not expose the HTTP/2 frame control gRPC needs. You use gRPC-Web with a proxy such as Envoy that translates between the browser and the real gRPC backend, or you expose a REST or GraphQL gateway in front.
Protocol Buffers is just the data format used to serialize messages. gRPC is the full framework that defines services, generates client and server code, and moves those messages over HTTP/2. gRPC uses protobuf by default but they are separate things.
Unary (one request, one response), server streaming (one request, a stream of responses), client streaming (a stream of requests, one response), and bidirectional streaming (both sides stream at once over one connection).
Often not. For public APIs consumed by web frontends or third-party developers, REST with JSON is easier to debug, test with curl, and adopt. gRPC is the stronger choice for internal, high-volume communication inside your own infrastructure.
Apache Thrift
Apache Thrift is a cross-language RPC framework built at Facebook. Learn its IDL and code generation, and see how it compares with gRPC and Protobuf.
Model Serving and Inference APIs: Turning a Model File Into a Service
How a trained model becomes a live API. Covers online vs batch serving, REST vs gRPC, dynamic batching, autoscaling and p99, with a batch simulator.
REST API
An architectural style for building APIs using standard HTTP methods (GET, POST, PUT, DELETE). Resources are identified by URLs.
GraphQL
A query language for APIs where the client specifies exactly what data it needs. No over-fetching, no under-fetching. One endpoint to rule them all.
Microservices
An architecture where an application is split into small, independent services that communicate over the network. Each service owns its own data and can be deployed separately.
WebSocket
A protocol for full-duplex communication over a single TCP connection. Unlike HTTP, the server can push data to the client without being asked.
SSE
Server-Sent Events: a one-way channel where the server pushes updates to the client over HTTP. Simpler than WebSockets when you only need server-to-client streaming.
Rate Limiting
Controlling how many requests a client can make in a given time window. Protects your API from abuse and ensures fair usage.
This page explains the idea. The "gRPC" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the gRPC lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about gRPC in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
