gRPC Interview Questions

A curated set of gRPC interview questions covering its trade-offs against REST, protobuf's wire format, the streaming models, and HTTP/2's role underneath it all.

gRPC vs REST#

Q: What are the main trade-offs between gRPC and REST? gRPC offers a strongly-typed, generated-code contract, compact binary payloads, and native streaming support, which suits internal service-to-service calls where you control both ends and want performance and strict contracts. REST/JSON is human-readable, universally supported by browsers and simple tools (curl, Postman), and easier for third parties to consume without special tooling — which is why public and browser-facing APIs still usually default to it.

Q: Why is gRPC a common choice for internal microservices specifically? Internal services are typically written and deployed by teams that control both client and server, can regenerate and redeploy stubs together, and care most about latency and throughput between services that talk to each other constantly — exactly where protobuf's compact binary encoding and HTTP/2's multiplexing pay off the most, without the downside (harder debuggability, browser incompatibility) mattering as much as it would for a public API.

Protobuf vs JSON#

Q: Why is protobuf generally smaller and faster than JSON? Protobuf encodes fields by number in a compact binary format, with no field names, punctuation, or whitespace repeated in every message — JSON is a text format that re-sends field names as strings in every single payload and must be parsed character by character. The trade-off is that protobuf isn't human-readable off the wire without the .proto schema to decode it, unlike JSON.

Q: What happens if the client and server disagree on a message's shape in protobuf? Protobuf's design specifically tolerates this within limits: adding a new field is safe (old code simply ignores it), and every field access falls back to a sensible default if it's missing. The unsafe case is reusing an existing field number for a different meaning, which is why removed fields should be marked reserved rather than deleted outright.

Streaming#

Q: Name the four gRPC RPC types and one use case for each. Unary (single request/response — a typical CRUD call), server streaming (one request, a stream of responses — a live price feed), client streaming (a stream of requests, one response — batched telemetry upload with a final summary), and bidirectional streaming (both sides stream independently — real-time chat).

Q: Why can't classic HTTP/1.1 REST easily express streaming RPCs the way gRPC does? HTTP/1.1 handles one request/response pair per connection at a time (or requires opening multiple connections for concurrency), with no standard way to keep a single logical exchange open for an extended, ongoing series of messages in both directions. HTTP/2's multiplexed, bidirectional streams are what make gRPC's streaming modes possible without piling on custom protocols like long-polling or WebSockets on top of REST.

HTTP/2#

Q: What does gRPC get specifically from running on HTTP/2 rather than HTTP/1.1? Multiplexing (many concurrent requests over one TCP connection, avoiding per-request connection overhead and head-of-line blocking), native bidirectional streaming support, and header compression — all of which plain HTTP/1.1 either lacks entirely or only approximates with workarounds.

Errors and bridging to REST#

Q: How does a gRPC service signal an application-level error, since it isn't using HTTP status codes? Through a status value carrying a code from a fixed canonical enumeration (codes.NotFound, codes.InvalidArgument, codes.Unauthenticated, and so on) plus a message, created with status.Error/status.Errorf and unpacked on the client with status.FromError. Returning a plain language-native error instead of a status loses this specificity, arriving on the client as a generic Unknown code.

Q: What problem does grpc-gateway solve? It lets a gRPC service also be called as ordinary REST/JSON by clients that can't speak gRPC directly — browsers being the most common case — by generating a reverse-proxy from google.api.http annotations already present in the .proto file. The proxy translates incoming JSON HTTP requests into gRPC calls and translates the responses back, without any change to the actual service implementation.