gRPC for internal communication in Microservices - System Design Guide

Problem Statement

When microservices communicate using traditional REST APIs with JSON over HTTP, the message size can be large and parsing can be slow, causing higher latency and increased CPU usage. This inefficiency becomes a bottleneck as the number of internal service calls grows, leading to slower response times and higher resource costs.

Solution

gRPC uses a compact binary protocol and HTTP/2 to enable fast, efficient communication between microservices. It defines service contracts with Protocol Buffers, which generate strongly typed client and server code, reducing errors and improving performance. This approach minimizes message size and supports multiplexing multiple calls over a single connection, lowering latency and resource consumption.

Architecture

┌───────────────┐       ┌───────────────┐
│   Service A   │──────▶│   Service B   │
│ (gRPC Client) │       │ (gRPC Server) │
└───────────────┘       └───────────────┘
        │                      ▲
        │ HTTP/2 + Protobuf    │
        └──────────────────────┘

This diagram shows Service A acting as a gRPC client sending requests over HTTP/2 with Protocol Buffers to Service B, the gRPC server, enabling efficient internal communication.

Trade-offs

✓ Pros

→

Reduces message size with binary serialization, improving network efficiency.

→

Supports multiplexing multiple requests over a single HTTP/2 connection, lowering latency.

→

Generates strongly typed client and server code, reducing bugs and improving developer productivity.

→

Built-in support for deadlines, cancellations, and streaming enhances robustness.

✗ Cons

→

Requires learning Protocol Buffers and gRPC tooling, adding initial complexity.

→

Less human-readable than JSON, making debugging network traffic harder without tools.

→

Not all languages or environments support gRPC equally, which can limit interoperability.

Use gRPC for internal microservice communication when you have high request volumes, need low latency, and want strong API contracts between services.

Avoid gRPC if your services require broad public API support with browsers or clients that do not support HTTP/2 or Protocol Buffers, or if your system is small with low communication overhead.

Real World Examples

Google

Google uses gRPC internally to connect its microservices efficiently, leveraging HTTP/2 multiplexing and Protocol Buffers for low-latency communication.

Netflix

Netflix adopted gRPC for internal service communication to reduce latency and improve throughput in their high-scale microservices environment.

Square

Square uses gRPC to enable fast, reliable communication between payment processing microservices, ensuring strong API contracts and efficient data exchange.

Code Example

The before code shows a simple REST call using JSON over HTTP, which is easy but less efficient. The after code uses gRPC with generated client stubs and Protocol Buffers, enabling faster, strongly typed communication with Service B.

Microservices

### Before: REST API call with JSON (naive approach)
import requests

def get_user_data(user_id):
    response = requests.get(f"http://serviceb/api/users/{user_id}")
    return response.json()


### After: gRPC client call with Protocol Buffers
import grpc
import user_pb2
import user_pb2_grpc

def get_user_data(user_id):
    with grpc.insecure_channel('serviceb:50051') as channel:
        stub = user_pb2_grpc.UserServiceStub(channel)
        request = user_pb2.UserRequest(id=user_id)
        response = stub.GetUser(request)
        return response

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 browsers and external clients is a priority and simplicity is preferred over performance.

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

Uses asynchronous messaging for decoupled communication rather than synchronous RPC calls.

Use when: Choose message queues when you need asynchronous processing, event-driven architecture, or loose coupling between services.

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 custom transport protocols or legacy system integration.

Summary

gRPC improves internal microservice communication by using efficient binary serialization and HTTP/2 multiplexing.

It enforces strong API contracts through Protocol Buffers, reducing errors and improving performance.

gRPC is best suited for high-scale, low-latency internal calls but is less ideal for public APIs requiring broad client support.

Practice

1. What is the main advantage of using gRPC for internal communication between microservices?

easy

A. It requires no predefined message formats.

B. It provides fast, efficient, and strongly typed communication.

C. It only works with services written in the same language.

D. It uses plain text messages for easy debugging.

Solution

1. Step 1: Understand gRPC communication benefits

   gRPC uses Protocol Buffers which are compact and strongly typed, making communication fast and reliable.

2. Step 2: Compare with other options

   Options B, C, and D are incorrect because gRPC requires predefined message formats, supports multiple languages, and uses binary messages, not plain text.

3. Final Answer:

   It provides fast, efficient, and strongly typed communication. -> Option B

4. Quick Check:

   gRPC speed and typing [OK]

Hint: gRPC is fast and typed, unlike plain text or language-specific methods [OK]

Common Mistakes:

• Thinking gRPC uses plain text messages
• Assuming gRPC works only with one language
• Believing gRPC needs no message definitions

2. Which of the following is the correct way to define a gRPC service method in a .proto file?

easy

A. method GetUser returns UserResponse(UserRequest);

B. service GetUser { rpc UserRequest returns UserResponse; }

C. rpc GetUser (UserRequest) returns (UserResponse);

D. function GetUser(UserRequest): UserResponse;

Solution

1. Step 1: Recall gRPC .proto syntax

   In .proto files, service methods are defined using the syntax: rpc MethodName (RequestType) returns (ResponseType);

2. Step 2: Validate options

   rpc GetUser (UserRequest) returns (UserResponse); matches the correct syntax. Options B, C, and D do not follow the .proto syntax for defining rpc methods.

3. Final Answer:

   rpc GetUser (UserRequest) returns (UserResponse); -> Option C

4. Quick Check:

   .proto rpc syntax [OK]

Hint: Remember: rpc Method(Request) returns (Response); in .proto files [OK]

Common Mistakes:

• Using 'service' keyword incorrectly for methods
• Confusing method syntax with programming language functions
• Omitting parentheses around request and response types

3. Given the following gRPC client call in Python, what will be the output if the server returns a UserResponse with name='Alice' and age=30?

response = stub.GetUser(UserRequest(id=123))
print(f"Name: {response.name}, Age: {response.age}")

medium

A. Name: Alice, Age: 30

B. Name: 123, Age: 0

C. Name: , Age:

D. Error: stub.GetUser is not a function

Solution

1. Step 1: Understand the client call and server response

   The client calls GetUser with id=123. The server responds with UserResponse containing name='Alice' and age=30.

2. Step 2: Analyze the print statement output

   The print statement accesses response.name and response.age, so it will output the values returned by the server.

3. Final Answer:

   Name: Alice, Age: 30 -> Option A

4. Quick Check:

   Client prints server response fields [OK]

Hint: Client prints server response fields directly as returned [OK]

Common Mistakes:

• Assuming client sends back request data instead of server response
• Confusing method call syntax causing errors
• Expecting empty or default values without server response

4. A developer wrote this gRPC service definition but the client fails to connect:

service UserService {
  rpc GetUser UserRequest returns UserResponse;
}

What is the error in this definition?

medium

A. Missing parentheses around request and response types.

B. Service name should be lowercase.

C. rpc keyword should be capitalized as RPC.

D. UserRequest and UserResponse must be strings.

Solution

1. Step 1: Check gRPC method syntax in .proto

   The correct syntax requires parentheses around request and response types: rpc MethodName (RequestType) returns (ResponseType);

2. Step 2: Identify the error in the given code

   The code misses parentheses around UserRequest and UserResponse, causing client connection failure.

3. Final Answer:

   Missing parentheses around request and response types. -> Option A

4. Quick Check:

   Parentheses required in rpc method signature [OK]

Hint: Always use parentheses around request and response in rpc methods [OK]

Common Mistakes:

• Ignoring parentheses in rpc method definitions
• Thinking service names must be lowercase
• Misunderstanding rpc keyword casing rules

5. You have multiple microservices written in different languages that need to communicate internally with low latency and strict message contracts. Which approach best fits this scenario?

hard

A. Use REST APIs with JSON for all communication.

B. Use message queues with XML messages.

C. Use plain TCP sockets with custom binary protocol.

D. Use gRPC with Protocol Buffers for internal communication.

Solution

1. Step 1: Analyze requirements for low latency and strict contracts

   Low latency and strict message contracts require efficient, strongly typed communication.

2. Step 2: Evaluate communication options

   REST with JSON is flexible but slower and less strict. Plain TCP with custom protocol is complex and error-prone. Message queues add latency and XML is verbose. gRPC with Protocol Buffers is designed for efficient, strongly typed, multi-language communication.

3. Final Answer:

   Use gRPC with Protocol Buffers for internal communication. -> Option D

4. Quick Check:

   Low latency + strict contracts = gRPC [OK]

Hint: gRPC + Protobuf = fast, typed, multi-language communication [OK]

Common Mistakes:

• Choosing REST despite latency and typing needs
• Using custom protocols without standard tooling
• Ignoring message size and parsing overhead