gRPC for internal services in HLD - System Design Guide

Problem Statement

When multiple internal services communicate using traditional REST APIs over HTTP/1.1, the overhead of verbose JSON payloads and slower serialization causes increased latency and higher CPU usage. This leads to slower response times and reduced throughput in high-scale microservices environments.

Solution

gRPC uses a compact binary protocol with HTTP/2 transport to enable fast, efficient communication between internal services. It serializes data using Protocol Buffers, reducing message size and parsing time. This mechanism allows services to call each other with low latency and supports features like streaming and built-in code generation for multiple languages.

Architecture

Internal

Service A

→Stub

↓

Internal

Service B

This diagram shows how Service A calls Service B internally using gRPC. The client stub serializes requests into compact protobuf messages sent over HTTP/2 to the server stub, which deserializes and invokes Service B logic.

Trade-offs

✓ Pros

→

Significantly reduces message size and serialization/deserialization time compared to JSON over HTTP/1.1.

→

Supports multiplexed streams and bi-directional streaming via HTTP/2, enabling efficient real-time communication.

→

Strongly typed contracts via Protocol Buffers reduce errors and improve developer productivity with auto-generated code.

→

Built-in support for deadlines, cancellations, and retries improves reliability in distributed systems.

✗ Cons

→

Requires learning Protocol Buffers syntax and tooling, adding initial developer overhead.

→

Less human-readable messages compared to JSON, complicating debugging without specialized tools.

→

HTTP/2 support may require updated infrastructure and load balancers that fully support HTTP/2 features.

Use gRPC for internal microservices communication when you need low latency, high throughput, and strong typing at scale, typically above hundreds of requests per second within a trusted network.

Avoid gRPC if your services require broad public API compatibility with browsers or clients that do not support HTTP/2 or protobuf, or if your traffic volume is low enough that JSON overhead is negligible.

Real World Examples

Google

Google developed gRPC to enable efficient communication between their internal microservices, reducing latency and improving scalability across their global infrastructure.

Netflix

Netflix uses gRPC internally to handle high-throughput service-to-service calls with low latency, especially for their edge services and streaming data pipelines.

Dropbox

Dropbox adopted gRPC to replace REST APIs for internal services, improving performance and enabling streaming file synchronization.

Alternatives

REST over HTTP/1.1

Uses text-based JSON over HTTP/1.1 without multiplexing or binary serialization.

Use when: Choose REST when interoperability with external clients and human-readable messages are priorities over performance.

Message Queue (e.g., Kafka, RabbitMQ)

Uses asynchronous messaging with decoupled producers and consumers instead of direct RPC calls.

Use when: Choose message queues when you need asynchronous, event-driven communication with guaranteed delivery.

Thrift

Similar to gRPC but uses its own binary protocol and supports multiple transport layers.

Use when: Choose Thrift if you require cross-language support with legacy systems or specific transport protocols.

Summary

gRPC improves internal service communication by using efficient binary serialization and HTTP/2 transport.

It reduces latency and CPU usage compared to traditional REST APIs with JSON over HTTP/1.1.

gRPC is best suited for high-scale microservices environments within trusted networks.