Can gRPC be used in a serverless environment (AWS Lambda), and what are the limitations (cold starts, no connection pooling, no streaming, API Gateway only supports gRPC-Web)?

• Lifecycle tension – gRPC assumes long-lived channels over persistent HTTP/2 connections, while Lambda is stateless, short-lived, and scales to zero.
• Cold start impact – the first invocation pays full TLS handshake and HTTP/2 setup cost; subsequent warm invocations reuse a static channel.
• No streaming – server, client, and bidirectional streaming require a durable connection that outlives a quick invocation.
• No native gRPC ingress – AWS API Gateway does not proxy gRPC framing to Lambda; use gRPC-Web with Envoy or ALB for native gRPC to containers.
• Practical pattern – Lambda as a gRPC client for bursty unary work; gRPC server on always-on containers behind an ALB.

What is the fundamental tension between gRPC and serverless?

gRPC performance comes from a long-lived channel over a persistent HTTP/2 connection. Connection warmup, TLS handshake, and HTTP/2 setup are amortized over many calls. A Lambda invocation is short and the execution environment may be frozen or destroyed between invocations, so the channel built in one invocation cannot be reliably reused in the next.

package com.bank.lambda;

import io.grpc.ManagedChannel;
import io.grpc.ManagedChannelBuilder;

public class LambdaGrpcClient {
    // Static field: reused across warm invocations
    private static final ManagedChannel CHANNEL =
        ManagedChannelBuilder.forAddress("account-service.internal", 443)
            .useTransportSecurity()
            .build();

    public static ManagedChannel getChannel() {
        return CHANNEL;
    }
}

How do cold starts affect gRPC in Lambda?

Cold starts hurt in two ways. First, the JVM and application startup latency. Second, building a gRPC channel requires a TLS handshake and HTTP/2 setup on the first call. Together these can add several seconds to the first invocation.

Mitigation strategies:

• Keep the channel in a static field so warm invocations reuse it.
• Use provisioned concurrency to keep environments warm.
• Use SnapStart for Java to snapshot the initialized JVM.
• Use lazy channel creation so the channel is built only when the first gRPC call actually happens.

package com.bank.lambda;

import com.bank.grpc.AccountServiceGrpc;
import com.bank.grpc.BalanceRequest;
import com.bank.grpc.BalanceResponse;
import java.math.BigDecimal;
import java.util.concurrent.TimeUnit;

public class BalanceHandler {
    private static final AccountServiceGrpc.AccountServiceBlockingStub STUB =
        AccountServiceGrpc.newBlockingStub(LambdaGrpcClient.getChannel())
            .withDeadlineAfter(2, TimeUnit.SECONDS);

    public BigDecimal handleRequest(String accountId) {
        BalanceRequest request = BalanceRequest.newBuilder()
            .setAccountId(accountId)
            .build();

        BalanceResponse response = STUB.getBalance(request);
        return new BigDecimal(response.getBalancePaise())
            .movePointLeft(2);
    }
}

Why is connection pooling unreliable?

Scale-out creates many Lambda environments, each with its own channel. Under high concurrency, this means many short-lived connections to the gRPC server, which can exhaust server-side connection limits. You lose gRPC's connection-reuse advantage.

Lambda environment 1 ──channel──▶ gRPC Server
Lambda environment 2 ──channel──▶ gRPC Server
Lambda environment 3 ──channel──▶ gRPC Server
   ...many more...

Each channel is independent. There is no shared connection pool across environments.

Why is streaming impractical in Lambda?

Server streaming, client streaming, and bidirectional streaming all assume a durable connection that outlives a quick invocation. A Lambda is bounded by a timeout (up to 15 minutes, typically much less for API calls). You cannot host an open stream for extended periods.

// This is impractical in Lambda:
// Server streaming response that sends account updates over time
// The Lambda would be torn down before the stream completes

// Practical in Lambda: unary call only
BalanceResponse response = stub
    .withDeadlineAfter(2, TimeUnit.SECONDS)
    .getBalance(request);

What are the API Gateway limitations?

AWS API Gateway (REST and HTTP APIs) does not proxy native gRPC to Lambda. It speaks HTTP/1.1 and HTTP/2 for its own protocols but not gRPC framing to functions.

Options:

• Use gRPC-Web with Envoy as a translating proxy for browser clients.
• Use an Application Load Balancer for native gRPC routing to always-on containers (ECS, EKS).
• Keep Lambda behind normal HTTP or event triggers, and route gRPC only to the container tier.

How should you architect gRPC with serverless?

The pragmatic architecture separates concerns:

| Component | Role | Platform |
|-----------|------|----------|
| gRPC server | Long-lived, streaming-capable | Always-on containers (ECS/EKS) behind ALB |
| gRPC client (unary) | Bursty, short-lived calls | Lambda (with static channel) |
| Browser access | gRPC-Web | Envoy proxy in front of containers |
| Event-driven work | Not gRPC | Lambda behind SQS, SNS, or HTTP |

package com.bank.lambda;

import com.bank.grpc.AccountServiceGrpc;
import com.bank.grpc.BalanceRequest;
import java.util.concurrent.TimeUnit;

public class BurstBalanceCheck {
    private static final AccountServiceGrpc.AccountServiceBlockingStub STUB =
        AccountServiceGrpc.newBlockingStub(LambdaGrpcClient.getChannel())
            .withDeadlineAfter(2, TimeUnit.SECONDS);

    public String check(String accountId) {
        var request = BalanceRequest.newBuilder()
            .setAccountId(accountId).build();
        var response = STUB.getBalance(request);
        return "Balance: " + response.getBalancePaise() + " paise";
    }
}

What are the best practices for gRPC in Lambda?

• Keep the channel in a static initializer for warm reuse.
• Set tight per-call deadlines so a hung call does not burn the whole Lambda timeout.
• Prefer unary calls over streaming.
• Use SnapStart to cut Java cold-start time.
• Monitor server-side connection counts, because high Lambda concurrency opens a flood of short-lived connections.
• Use provisioned concurrency for latency-sensitive paths.

What about connection discipline on the server side?

High Lambda concurrency can open many short-lived connections that overwhelm the gRPC server. Configure server-side max-connection limits and use client-side load balancing. The gRPC server should set MAX_CONCURRENT_STREAMS and connection age limits.

// Server-side: limit connections and enforce age
Server server = ServerBuilder.forPort(443)
    .addService(new AccountServiceImpl())
    .maxInboundMessageSize(4 * 1024 * 1024)
    .keepAliveTime(30, TimeUnit.SECONDS)
    .maxConnectionAge(5, TimeUnit.MINUTES)
    .build();

What are common interview follow-up questions?

• How does SnapStart help with gRPC cold starts?
• What is the difference between gRPC-Web and native gRPC?
• How would you handle a gRPC streaming use case if the consumer is Lambda?
• What happens when the gRPC server hits its connection limit from Lambda scale-out?