gRPC vs REST for Internal Microservices APIs: A Practical Comparison

Independent benchmarks show gRPC delivering up to 77% lower latency and 107% higher throughput compared to REST for small payloads, with 10x reduction in serialized message size thanks to Protocol Buffers. Those are numbers worth paying attention to. But I've built internal APIs with both, and the honest answer is: the protocol choice rarely determines system performance in practice. What matters more is your payload design, connection pooling, and whether your team can actually operate what you build. This guide walks through when gRPC's advantages are real and when REST's simplicity wins.

What Makes gRPC Different

gRPC uses HTTP/2 as its transport layer and Protocol Buffers (protobuf) as its serialization format. HTTP/2 enables multiplexed streams over a single connection — multiple requests and responses in flight simultaneously without head-of-line blocking. Protobuf serializes data into compact binary format, typically 3-10x smaller than equivalent JSON. gRPC also generates strongly-typed client and server stubs from a .proto schema file, eliminating the need to maintain separate API documentation or deal with runtime type errors.

The Four gRPC Communication Patterns

gRPC supports four patterns: Unary (one request, one response — equivalent to REST), Server Streaming (one request, stream of responses — good for real-time feeds), Client Streaming (stream of requests, one response — good for file uploads), and Bidirectional Streaming (full duplex — good for chat or real-time collaboration). REST can approximate these patterns with SSE or WebSockets, but gRPC makes them first-class patterns with generated code.

Traffic Pattern Decision Guide

  NORTH-SOUTH (External Traffic)
  ─────────────────────────────────────────────────
  Browser / Mobile App / Partner API
         │
         ▼  HTTP/1.1 + JSON (REST)
  ┌─────────────────┐
  │   API Gateway   │   ← Use REST here
  │   (Public API)  │
  └────────┬────────┘
           │
           │ EAST-WEST (Internal Traffic)
  ─────────┼───────────────────────────────────────
           │  HTTP/2 + Protobuf (gRPC)
    ┌──────┴──────┬──────────────┐
    ▼             ▼              ▼
  Order        Inventory     Payment
  Service      Service       Service
  (NestJS)    (NestJS)      (NestJS)
     │             │              │
     └─────────────┴──────────────┘
          gRPC — 77% lower latency
           10x smaller payloads

Implementing gRPC in NestJS

NestJS has native gRPC support via @nestjs/microservices. You define a .proto file, configure the gRPC transport in your microservice, and use @GrpcMethod or @GrpcStreamMethod decorators on your handlers. On the client side, you inject a ClientGrpc instance and call methods directly as TypeScript functions. The generated types give you compile-time safety across service boundaries — if you change the proto schema, TypeScript will catch all callers that need updating.

// inventory.proto
syntax = "proto3";
package inventory;

service InventoryService {
  rpc CheckStock (CheckStockRequest) returns (CheckStockResponse);
  rpc StreamInventory (Empty) returns (stream InventoryUpdate);
}

message CheckStockRequest { string product_id = 1; }
message CheckStockResponse { int32 quantity = 1; bool available = 2; }

// inventory.controller.ts (NestJS gRPC handler)
@Controller()
export class InventoryController {
  @GrpcMethod('InventoryService', 'CheckStock')
  async checkStock(data: CheckStockRequest): Promise<CheckStockResponse> {
    const stock = await this.inventoryRepo.getStock(data.productId);
    return { quantity: stock.quantity, available: stock.quantity > 0 };
  }
}

// order.service.ts (gRPC client)
@Injectable()
export class OrderService {
  private inventoryService: InventoryServiceClient;

  onModuleInit() {
    this.inventoryService = this.client.getService<InventoryServiceClient>('InventoryService');
  }

  async createOrder(dto: CreateOrderDto) {
    const stock = await firstValueFrom(
      this.inventoryService.checkStock({ productId: dto.productId })
    );
    if (!stock.available) throw new ConflictException('Out of stock');
    // proceed with order creation...
  }
}

Performance Numbers That Matter

A 2025 benchmark study comparing gRPC and REST under equivalent load found: gRPC delivered 48% lower average latency for small payloads (under 1KB), 19% lower CPU usage, 34% lower memory consumption, and 41% lower network bandwidth. For a high-frequency internal API — say, an order service querying an inventory service thousands of times per minute — these gains compound into meaningful infrastructure cost savings. For a low-frequency admin API called a few times per minute, the protocol choice is irrelevant.

When REST Still Wins

REST remains the right choice when: your API is consumed by browsers or external clients; your team is primarily REST-experienced and adoption cost outweighs performance gains; you need simple curl-based testing and standard HTTP tooling; your request rate is low enough that protocol efficiency doesn't matter. The industry consensus is to use gRPC for east-west traffic where both ends are owned internally, and REST for north-south traffic where third parties (browsers, mobile apps, partner integrations) need to call in.

GraphQL as a Third Option

For internal APIs where query flexibility matters more than throughput — like a BFF (Backend for Frontend) aggregating multiple microservices — GraphQL is worth considering. GraphQL lets clients request exactly the fields they need, reducing over-fetching. But GraphQL has its own operational overhead: schema stitching, N+1 query problems, caching complexity. For simple service-to-service calls with well-defined contracts, GraphQL adds more complexity than it solves.

My Decision Framework

High-frequency internal service calls (>1000/min): use gRPC for the latency and bandwidth savings. Low-frequency internal service calls: use REST for simplicity. Public-facing APIs: always REST. Data streaming (real-time feeds, large file transfers): gRPC streaming. Team with no gRPC experience on a deadline: REST first, migrate if you hit actual performance problems. Architecture decisions should be driven by measured bottlenecks, not benchmarks from someone else's hardware.

Sources & Further Reading