gRPC — Fast Communication Between Services

gRPC is a high-performance RPC (Remote Procedure Call) framework that allows one application or service to call methods on another service over a network.

It is commonly used for service-to-service communication in distributed systems and microservices.

1. Why Do We Need gRPC?

In a microservices architecture, different services need to communicate with each other.

flowchart LR
Order["Order Service"]
Payment["Payment Service"]
Inventory["Inventory Service"]

Order --> Payment
Order --> Inventory

REST APIs can be used for this communication, but gRPC provides a strongly-typed contract and efficient binary communication.

2. How gRPC Works

Instead of sending a typical JSON REST request, gRPC commonly uses Protocol Buffers (Protobuf) to define the service contract and serialize data.

flowchart LR
Client["gRPC Client"]
Proto["Protobuf Contract"]
Server["gRPC Server"]

Client --> Proto
Proto --> Server

3. Protocol Buffers

A gRPC service is commonly defined using a .proto file.

syntax = "proto3";

service PaymentService {
  rpc GetPayment (PaymentRequest)
      returns (PaymentResponse);
}

message PaymentRequest {
  int32 paymentId = 1;
}

message PaymentResponse {
  int32 paymentId = 1;
  string status = 2;
}

The .proto file acts as a contract between the client and server.

4. gRPC Request Flow

sequenceDiagram
Client->>PaymentService: GetPayment(1001)
PaymentService->>Database: Get payment
Database-->>PaymentService: Payment data
PaymentService-->>Client: PaymentResponse

The client calls a remote method almost like calling a local method.

5. gRPC Uses HTTP/2

gRPC is designed to use HTTP/2.

HTTP/2 provides features such as:

• Multiplexing
• Binary framing
• Header compression
• Persistent connections

flowchart LR
Client --> HTTP2["HTTP/2"]
HTTP2 --> Server

6. gRPC Communication Types

gRPC supports four communication patterns.

Type	Description
Unary	One request → One response
Server Streaming	One request → Multiple responses
Client Streaming	Multiple requests → One response
Bidirectional Streaming	Multiple requests ↔ Multiple responses

7. Unary RPC

This is similar to a traditional request-response API.

sequenceDiagram
Client->>Server: Request
Server-->>Client: Response

8. Server Streaming

The client sends one request and the server sends multiple responses.

sequenceDiagram
Client->>Server: Request
Server-->>Client: Response 1
Server-->>Client: Response 2
Server-->>Client: Response 3

9. Client Streaming

The client sends multiple messages and the server returns one response.

sequenceDiagram
Client->>Server: Request 1
Client->>Server: Request 2
Client->>Server: Request 3
Server-->>Client: Final Response

10. Bidirectional Streaming

Both client and server can continuously send messages.

sequenceDiagram
Client->>Server: Message 1
Server-->>Client: Message 1
Client->>Server: Message 2
Server-->>Client: Message 2
Client->>Server: Message 3
Server-->>Client: Message 3

11. gRPC vs REST

REST	gRPC
Usually JSON	Usually Protobuf
HTTP/1.1 or HTTP/2	Designed for HTTP/2
Resource-oriented	Service/method-oriented
Easy browser integration	Better suited to service-to-service communication
Simple and widely understood	Strongly typed contract
Human-readable JSON	Compact binary serialization

12. gRPC in Microservices

gRPC is particularly useful when multiple backend services need efficient communication.

flowchart LR
Gateway["API Gateway"]
Order["Order Service"]
Payment["Payment Service"]
Inventory["Inventory Service"]

Gateway --> Order
Order -->|gRPC| Payment
Order -->|gRPC| Inventory

For example, an Order Service can call Payment and Inventory services using strongly typed gRPC contracts.

13. gRPC in ASP.NET Core

ASP.NET Core provides built-in support for creating gRPC services.

public class PaymentService : Payment.PaymentBase
{
    public override Task<PaymentResponse> GetPayment(
        PaymentRequest request,
        ServerCallContext context)
    {
        return Task.FromResult(new PaymentResponse
        {
            PaymentId = request.PaymentId,
            Status = "Completed"
        });
    }
}

The generated base classes and message types come from the Protobuf contract.

14. When Should You Use gRPC?

Common scenarios include:

• Microservice-to-microservice communication
• High-throughput internal APIs
• Low-latency service communication
• Strongly typed service contracts
• Streaming communication

15. When REST May Be More Appropriate

REST is often convenient when APIs are primarily consumed by browsers, mobile applications, external clients, or third-party developers.

REST's widespread HTTP and JSON support makes it straightforward for many clients to consume.

16. Important Interview Questions

• What is gRPC?
• Why does gRPC use Protocol Buffers?
• What protocol does gRPC use underneath?
• What is HTTP/2?
• What are the four types of gRPC communication?
• What is unary RPC?
• What is streaming in gRPC?
• gRPC vs REST?
• Why is gRPC commonly used between microservices?
• Can a browser directly consume gRPC?
• How does gRPC work in ASP.NET Core?

Key Takeaways

• gRPC is a high-performance RPC framework.
• It commonly uses HTTP/2 and Protocol Buffers.
• It provides strongly typed service contracts.
• It supports unary and streaming communication.
• It is commonly used for internal microservice communication.
• REST is generally more convenient for broad client and browser consumption.

Conclusion

REST is generally resource-oriented and uses HTTP semantics, while gRPC is service-oriented and allows clients to call strongly typed remote methods.

In system design interviews, the key discussion is usually REST vs gRPC, especially around performance, contracts, browser compatibility, streaming, and microservice communication.