Skip to main content
Let’s break down how gRPC differs from standard HTTP protocols and why it matters for modern microservices. One key point to be clear about: gRPC does not replace HTTP — it runs on top of HTTP/2.
gRPC uses HTTP/2 as its transport layer. Knowing how HTTP/2 works explains many of gRPC’s performance and operational advantages.
Example scenario: an Uber-style rider app Consider the backend of a ride-hailing app. When a rider taps “Request a ride,” the trip service fans out multiple calls: it queries the driver service for nearby cars, the pricing service for a fare estimate, the location service for live tracking, and the notification service to alert drivers. One user action can generate many internal service calls per request.
The image illustrates a comparison between gRPC and HTTP, featuring an Uber-style ride app diagram with various service components like driver, location, trip service, pricing, and notification. It highlights that a single "Request a Ride" tap can result in 15-20 calls.
At production scale, services like this may exchange thousands of RPC/external calls per second. The underlying protocol you choose affects latency, bandwidth, CPU usage, and developer ergonomics. Why HTTP/1.1 can be inefficient for high-volume service-to-service traffic
  • HTTP/1.1 often requires separate TCP connections (or a very limited number of simultaneous connections) to achieve parallelism. Clients and browsers typically limit concurrent connections.
  • New connections imply fresh TCP and TLS handshakes, adding tens to hundreds of milliseconds of latency depending on network conditions.
  • Head-of-line blocking on a connection can delay subsequent requests if one is slow.
  • Each request sends repeated plain-text headers (authorization tokens, trace IDs, etc.), which can be hundreds of bytes per request and waste bandwidth at scale.
The image illustrates HTTP/1.1 problems, including head-of-line blocking and header repetition as plain text. It shows issues like one request per connection, slow queue waits, and a maximum of six connections.
How HTTP/2 improves things
  • Multiplexing: a single TCP/TLS connection carries many concurrent streams (lightweight channels), so you avoid many parallel handshakes.
  • Header compression (HPACK): repeated headers are compressed using a shared state table, so subsequent requests send far fewer header bytes.
  • Better utilization of an existing secure connection reduces CPU and latency overhead for many short-lived calls.
Note: HTTP/2 eliminates application-level head-of-line blocking by multiplexing streams, but it can still suffer from TCP-level head-of-line blocking if packets are lost. HTTP/3 (QUIC) addresses that by using UDP-based independent streams.
The image illustrates how HTTP/2 improves performance by using a single connection with multiple parallel streams and header compression.
What gRPC adds on top of HTTP/2 gRPC combines HTTP/2 transport with two main features that make it compelling for internal APIs and microservices:
  1. Compact binary serialization — Protocol Buffers (protobuf)
    • Protobuf is a binary, strongly typed serialization format. Binary encodings are smaller on the wire and faster for machines to parse than verbose JSON.
    • Example JSON:
    • Equivalent protobuf bytes (hex view):
    • Smaller payloads and cheaper parsing reduce latency and CPU usage at scale.
  2. Strongly typed service contract in a .proto file
    • A single .proto file defines your service, RPC methods, and message types. From that file, code generators produce client and server stubs in many languages, ensuring both sides share the same contract.
    • Example service definition:
    • Generated client code makes a remote call look like a local function:
    • gRPC handles serialization, HTTP/2 transport, and deserialization under the hood.
Quick comparison: HTTP/1.1 vs HTTP/2 vs gRPC Where gRPC is a good fit
Use gRPC for internal service-to-service communication where you need high throughput, low latency, compact binary payloads, and a strong typed contract across languages. For public-facing APIs (browsers, third-party integrations), REST/HTTP+JSON remains widely supported and easier for clients without gRPC tooling.
Summary
  • gRPC runs on top of HTTP/2 and gains multiplexing and header-compression benefits from that transport.
  • gRPC adds protobuf binary encoding (smaller/faster) and a .proto service contract that generates client/server code.
  • For high-volume internal microservices, gRPC often outperforms HTTP/JSON solutions in latency, bandwidth, and developer productivity. For public, human-facing APIs, REST/JSON is still common due to broad client support.
Links and references

Watch Video