gRPC — Interview Q&A Matrix

Parent stack: Messaging & Integration Technology: gRPC Levels: Senior Questions: 1

Each entry contains a Question, the Expected Depth, an Ideal Answer, and Red Flags.

Senior

Q1 — Choosing between REST and gRPC

Question: When would you choose gRPC instead of REST for service-to-service communication, and what operational concerns must you handle?

Expected Depth:

• Explains gRPC's contract-first model, Protobuf encoding, generated clients, and HTTP/2 transport.
• Compares unary, server-streaming, client-streaming, and bidirectional-streaming calls.
• Chooses based on API users, latency, payload size, streaming needs, caching, and tooling rather than saying only "gRPC is faster."
• Uses deadlines, cancellation, status codes, and safe retry rules.
• Understands HTTP/2 load balancing, connection reuse, flow control, message-size limits, and browser constraints.
• Evolves Protobuf schemas without reusing field numbers or making unsafe type changes.
• Covers TLS or mTLS, authentication metadata, tracing, metrics, logging, and debugging tools.

Ideal Answer:

• Choose gRPC when internal services need a strict contract, generated clients, compact messages, or streaming. HTTP/2 allows several calls on one connection, and Protobuf normally creates smaller payloads than JSON.
• Choose REST/JSON when the API is public or browser-facing, easy manual debugging is important, HTTP caching is useful, or clients cannot use gRPC tooling.
• gRPC is not always faster. REST can also use HTTP/2, and performance depends on payload size, network latency, serialization cost, server work, and connection design. Measure the real workload.
• gRPC supports four call types:
• Unary: one request and one response.
• Server streaming: one request and many responses.
• Client streaming: many requests and one response.
• Bidirectional streaming: both sides send a stream of messages.
• Define the contract in a .proto file:

syntax = "proto3";

package pricing.v1;

service PricingService {
  rpc GetQuote(GetQuoteRequest) returns (QuoteReply);
  rpc StreamTicks(StreamTicksRequest) returns (stream Tick);
}

message GetQuoteRequest {
  string product_id = 1;
  optional string customer_id = 2;
}

message QuoteReply {
  string product_id = 1;
  int64 amount_minor = 2;
  string currency = 3;
}

message StreamTicksRequest {
  repeated string product_ids = 1;
}

message Tick {
  string product_id = 1;
  int64 amount_minor = 2;
  int64 observed_at_epoch_ms = 3;
}

• Every client call should have a deadline. Without one, a slow dependency can keep work and resources open for too long:

QuoteReply reply = pricingStub
        .withDeadlineAfter(300, TimeUnit.MILLISECONDS)
        .getQuote(request);

• A deadline also supports cancellation propagation. Server code should stop expensive work when the client cancels or the deadline expires.
• Return a suitable gRPC status instead of a generic UNKNOWN error:

if (request.getProductId().isBlank()) {
    responseObserver.onError(Status.INVALID_ARGUMENT
            .withDescription("product_id is required")
            .asRuntimeException());
    return;
}

• Retry only transient failures such as UNAVAILABLE, and use exponential backoff with jitter. Retry an operation only when it is idempotent or protected by an idempotency key. Do not retry INVALID_ARGUMENT or other permanent errors.
• Streaming uses HTTP/2 flow control, but the application can still produce data faster than a consumer can process it. Use bounded buffers and manual inbound flow control for large streams.
• Use TLS for transport security and mTLS when services must verify each other's identity. Send access tokens or trace context through metadata, but never log secrets.
• gRPC requires HTTP/2-aware proxies and load balancers. Long-lived connections can make simple connection-level balancing uneven, so use gRPC-aware client-side or L7 load balancing.
• Browsers need gRPC-Web and usually a proxy, or a REST/JSON gateway. Native gRPC is not directly available through normal browser APIs.
• Add tracing interceptors, latency and status metrics, structured logs, health checks, and reflection where security policy allows it. Tools such as grpcurl help inspect and test services.
• Evolve Protobuf contracts with additive changes:
• Add new fields with new field numbers.
• Never renumber or reuse an existing field number.
• Reserve removed field numbers and names.
• Do not change a field to an incompatible wire type.
• Use optional when scalar field presence matters.

message QuoteReply {
  reserved 4;
  reserved "legacy_discount";

  string product_id = 1;
  int64 amount_minor = 2;
  string currency = 3;
  optional string discount_code = 5;
}

• Package and service names are also part of the API. For a breaking change, publish a new version such as pricing.v2 and support both versions during migration.

Red Flags:

• Chooses gRPC only because it is "faster" and provides no measurements or requirements.
• Uses gRPC for a browser API without gRPC-Web or a gateway.
• Makes calls without deadlines or ignores cancellation.
• Retries every failure, including non-idempotent operations and permanent status codes.
• Returns UNKNOWN for all errors or exposes internal exception messages to clients.
• Reuses, renumbers, or changes the wire type of a Protobuf field.
• Removes a field without reserving its number and name.
• Ignores flow control, message-size limits, or uneven load across long-lived HTTP/2 connections.
• Sends plaintext traffic or puts secrets in logs and error messages.
• Has no tracing, metrics, health checks, or way to debug production calls.

Scoring Rubric