In this article
The contract and the call types
What is gRPC and how does a call work?
gRPC is a framework where you describe a service once and the tooling generates client and server code from it. The client calls a local object, a stub, which turns the arguments into bytes with protocol buffers and sends them over Hypertext Transfer Protocol version 2 (Hypertext Transfer Protocol (HTTP)/2) (gRPC core concepts, accessed October 2026; Kreya, accessed October 2026). The server decodes the bytes, runs the method and sends a reply back the same way.
Why it is asked: it checks that you can describe the whole path in a few sentences. Source: gRPC core concepts.
What is a .proto file, and what are protocol buffers?
A .proto file is the contract: it lists the services, their methods and the message types. Starting from it, gRPC provides compiler plugins that generate client-side and server-side code (gRPC core concepts, accessed October 2026). Protocol buffers, often called protobuf, are both the Interface Definition Language (IDL) in which the file is written and the serialization format for the messages.
Why it is asked: contract-first design is the main difference from many plain web interfaces. Source: Kreya, gRPC deep dive.
What are the four kinds of gRPC method?
gRPC defines four kinds of service method (gRPC core concepts, accessed October 2026). A unary call sends one request and gets one response, like a normal function call. Server streaming sends one request and reads a stream of messages back. Client streaming writes a stream of messages and gets a reply. Bidirectional streaming lets both sides send sequences over a read-write stream.
Why it is asked: the right choice depends on the data shape, for example a feed versus an upload. Source: gRPC core concepts.
Is message order preserved in gRPC?
Ordering is preserved within a single RPC call: messages on one stream arrive in the order they were sent (gRPC core concepts, accessed October 2026). Nothing in that statement orders separate calls against each other, so two concurrent calls can finish in either order. If your design needs a global order, add sequence numbers or send the operations through one stream or one queue.
Why it is asked: it separates per-call ordering from the global ordering many candidates assume. Source: gRPC core concepts.
Does gRPC always use protobuf?
By default, yes: the documentation says gRPC uses protocol buffers by default (gRPC core concepts, accessed October 2026). The words "by default" matter, since other data formats can be used, but protobuf is what generated code and most tooling assume. In an interview, answer with the default and name the trade-off of leaving it.
Why it is asked: precise wording shows you read the documentation, not a summary. Source: gRPC core concepts.
Transport: HTTP/2, channels and load balancing
How does gRPC use HTTP/2?
Every gRPC call, whether a simple unary request or a long-lived bidirectional stream, maps to a single HTTP/2 stream (Kreya, accessed October 2026). A call goes from the client stub through a channel into one HTTP/2 stream, and many streams share one TCP (Transmission Control Protocol) connection with their frames interleaved.
Text description of the diagram
- A call goes from the client stub through a channel into one HTTP/2 stream.
- Many streams share one TCP connection.
Why it is asked: it tests whether you know why gRPC needs fewer connections than request-per-connection designs. Source: Kreya, gRPC deep dive.
Does gRPC open a new connection for every call?
No. Calls are multiplexed as HTTP/2 streams over a connection that is reused, so many active calls can share one TCP connection (Kreya, accessed October 2026). The cost is that a connection becomes long-lived and carries a lot of traffic, which matters for load balancing. A server also limits how many streams one connection may carry at once; when that limit is reached, further calls queue in the client until active ones finish, so a busy application uses a separate channel or a pool of channels to spread calls over more connections (gRPC performance guide, accessed October 2026).
Why it is asked: it corrects a common misconception about connection cost. Source: gRPC performance best practices.
What is a channel, and what is a stub?
A channel is a connection to a gRPC server on a given host and port, and it is used when creating a client stub (gRPC core concepts, accessed October 2026). A stub is the generated client object you call methods on. Channels also take part in name resolution and load balancing (gRPC load balancing, accessed October 2026). Create one channel and reuse it.
Why it is asked: creating a channel per request is a typical performance mistake. Source: gRPC core concepts, Channels.
Why is load balancing harder with gRPC?
Because many calls share one long-lived connection, a balancer that only spreads connections can leave one server with all the calls of a busy client. The gRPC project describes two approaches: a proxy that balances individual calls, or client-side balancing, where the client picks a server per call (gRPC load balancing, accessed October 2026). In a design round, state which one you chose and why.
Why it is asked: it tests whether you can follow a transport property to its operational consequence. Source: gRPC load balancing blog.
How does flow control work, and what is backpressure on a stream?
HTTP/2 uses window-based flow control: the receiver announces how much data it is willing to accept, and the sender stops when that window is used up until the receiver reads and grants more (gRPC flow control guide, accessed October 2026). On a stream this slows a fast producer when the consumer is slow, which is backpressure. Without it, a slow reader would make the sender buffer without bound.
Why it is asked: it separates people who have run streaming services from people who have only read about them. Source: gRPC flow control.
What are keepalive and health checking for?
Keepalive sends periodic HTTP/2 pings so each side can notice a dead connection, and stops idle connections being dropped silently by network devices; servers may refuse clients that ping too often (gRPC keepalive guide, accessed October 2026). Health checking is a standard service, grpc.health.v1, that a client, balancer or orchestrator calls to ask whether a server is ready (gRPC health checking guide, accessed October 2026).
Why it is asked: long-lived connections fail in quiet ways, and interviewers look for how you detect them. Source: gRPC health checking.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Data format and schema
Why is a protobuf message smaller than the same JSON?
Protobuf identifies a field by a small number instead of a name and stores integers as varints (Protocol Buffers encoding guide, accessed October 2026). A varint is a variable-length integer that uses fewer bytes for small values. In a worked example, a message with id 150 and name "ann" takes 8 bytes in protobuf and 23 bytes as compact JavaScript Object Notation (JSON) text.1 The field name is never sent, only its number.
Why it is asked: it checks that you can reason about payload size with real arithmetic. Source: protobuf encoding.
| Part of the message | Protobuf bytes | JSON characters |
|---|---|---|
| id field (150) | 3 (08 96 01) | 9 ("id":150,) |
| name field ("ann") | 5 (12 03 61 6e 6e) | 12 ("name":"ann") |
| braces | 0 | 2 |
| Whole message | 8 | 23 |
The id value 150 is split into 7-bit groups; the first byte 96 carries the low bits with a continuation flag, and 01 carries the rest.1
How do you change a protobuf schema without breaking clients?
A field is known by its number, so you may add new fields with new numbers, and you should never reuse or renumber an existing one (proto3 guide, Updating A Message Type, accessed October 2026). Old code ignores fields it does not know, and a missing field reads as its default value. To remove a field, mark its number and name with the reserved keyword so nobody recycles them for another meaning.
Why it is asked: compatibility during a rolling deployment is a daily problem. Read the full explanation: application programming interface (API) design interview questions.
Reliability: deadlines, errors and retries
What is a deadline and why should every call have one?
A deadline is the point in time by which a call must finish. Clients specify how long they are willing to wait, and when it passes the call ends with a DEADLINE_EXCEEDED error (gRPC core concepts, accessed October 2026; deadlines guide). A slow dependency then cannot hold resources forever. Pass the remaining time to downstream calls, so a chain of services stops work nobody is waiting for.
Why it is asked: it shows you think about failure, not only the happy path. Read the full explanation: what tail latency is.
How does cancellation work?
Either the client or the server can cancel an RPC at any time, and cancellation ends the call immediately so no further work is done (gRPC core concepts, accessed October 2026). It is not a rollback: changes made before the cancel stay. Many implementations let a cancelled parent call cancel the calls made on its behalf, so check how your language does it (cancellation guide).
Why it is asked: it tests whether you design handlers that stop work and stay safe when stopped midway. Source: gRPC cancellation guide.
How does gRPC report errors?
Every call ends with a status made of a code and an optional message, separate from any HTTP status. Codes such as NOT_FOUND, UNAVAILABLE and DEADLINE_EXCEEDED let a client decide whether to retry, fix the request or give up (gRPC status codes guide, accessed October 2026). Return the most specific code the situation allows, and keep the message free of secrets.
Why it is asked: a clear error model is part of a good interface. Source: gRPC status codes.
When is it safe to retry a gRPC call?
A retry is safe when the call is idempotent, meaning running it twice has the same effect as running it once. Reading a record is idempotent; charging a card is not unless you attach a key that lets the server recognize the repeat. gRPC supports retries through a retry policy in the service config, with a maximum number of attempts, backoff and the status codes to retry (gRPC retry guide, accessed October 2026). Without limits, retries multiply load on a struggling server.
Why it is asked: unbounded retries cause outages, and interviewers look for that awareness. Read the full explanation: how to design a payment system.
Choosing gRPC
How does gRPC differ from REST?
Representational state transfer (REST) usually means resources and verbs over HTTP with JSON, readable in a browser. gRPC is contract-first: methods and messages are defined upfront in .proto files (Kreya, accessed October 2026), the payload is binary, and streaming is built in. A common bridge is a gateway that transcodes HTTP/JSON requests into gRPC calls, as gRPC-Gateway does. Neither is faster in every case; measure your own workload before claiming a number.
Why it is asked: it tests judgement, not loyalty to a tool. Read the full explanation: REST API interview questions.
Can a browser call a gRPC service directly?
Not as plain gRPC. Browser code uses gRPC-Web, a variant of the protocol that browsers can speak, which a proxy or the server translates into regular gRPC (gRPC-Web documentation, accessed October 2026). For outside parties, a webhook or a REST interface is often simpler.
Why it is asked: it checks that you know where gRPC fits and where it does not. Source: gRPC-Web.
What are metadata and interceptors?
Metadata is a set of key-value pairs sent alongside a call, such as an authentication token or a request id, separate from the message body (gRPC metadata guide, accessed October 2026). An interceptor is code that wraps every call on the client or the server, so cross-cutting work such as logging, authentication and metrics lives in one place instead of every method (gRPC interceptors guide, accessed October 2026).
Why it is asked: it shows whether you keep cross-cutting concerns out of business logic. Source: gRPC interceptors.
How do you secure a gRPC service?
Encrypt the connection with Transport Layer Security (TLS) so traffic between client and server cannot be read or altered on the way. Authenticate each call with a token sent as call credentials in metadata (the key-value pairs sent with a call), and put the checks every method needs in an interceptor (shared code that wraps each call) (gRPC authentication guide, accessed October 2026).
Why it is asked: security is expected in every service design. Read the full explanation: backend interview questions.
When would you pick gRPC in a system design round?
Pick it for calls between your own services where you control both ends, need streaming, or want one typed contract across languages. Pick REST for public interfaces and browsers. Say the reason, name the cost (binary payloads are harder to inspect, and balancing needs thought) and mention how you would test it.
Why it is asked: design rounds reward a stated trade-off. Read the full explanation: distributed systems interview questions.
Follow-up questions
How do you design a gRPC API that can evolve for years?
Add fields rather than change them, reserve the numbers of removed fields, and treat new behavior as new methods or a new package version. Keep old and new servers running side by side during a rollout, as the application programming interface (API) design questions explain.
Is gRPC faster than REST?
Often less data is sent and one connection carries many calls, but no benchmark is cited here, so the honest answer is that it depends on payload, network and code. Measure with your own traffic, and use back-of-the-envelope estimation to size it first.
Does gRPC deliver every message?
No. A call can fail, time out or be cancelled, and the status tells the client which. Order is preserved within one call, but a client must decide whether to retry, which is why idempotency matters.
How do you test a gRPC service?
Call it with generated stubs in unit and integration tests, test deadlines and error codes on purpose, and use a command-line or desktop client to send ad hoc requests. Include a case where the server is slow.
- Each call maps to one HTTP/2 stream, and many calls share one connection.
- gRPC has four method types: unary, server streaming, client streaming and bidirectional streaming.
- Order holds within one call, not across calls.
- Set deadlines, retry only idempotent calls and balance per call, not per connection.
- Protobuf identifies fields by number, so never reuse a number.
Sources
- Core concepts, architecture and lifecycle (gRPC documentation) — gRPC (official documentation), 26 Oct 2026
- Deadlines (gRPC documentation) — gRPC (official documentation), 26 Oct 2026
- Status codes and their use in gRPC — gRPC (official documentation), 26 Oct 2026
- Retry (gRPC documentation) — gRPC (official documentation), 26 Oct 2026
- Authentication (gRPC documentation) — gRPC (official documentation), 26 Oct 2026
- Interceptors (gRPC documentation) — gRPC (official documentation), 26 Oct 2026
- Metadata (gRPC documentation) — gRPC (official documentation), 26 Oct 2026
- Flow control (gRPC documentation) — gRPC (official documentation), 26 Oct 2026
- Cancellation (gRPC documentation) — gRPC (official documentation), 26 Oct 2026
- Keepalive (gRPC documentation) — gRPC (official documentation), 26 Oct 2026
- Health checking (gRPC documentation) — gRPC (official documentation), 26 Oct 2026
- Performance best practices (gRPC documentation) — gRPC (official documentation), 26 Oct 2026
- gRPC load balancing (gRPC blog) — gRPC (official blog), 26 Oct 2026
- gRPC-Web (gRPC documentation) — gRPC (official documentation), 26 Oct 2026
- Language guide (proto3), Updating A Message Type — Protocol Buffers (official documentation), 26 Oct 2026
- Protocol Buffers encoding — Protocol Buffers (official documentation), 26 Oct 2026
- gRPC-Gateway (official repository) — gRPC Ecosystem (GitHub), 26 Oct 2026
- gRPC deep dive: from service definition to wire format — Kreya, 26 Oct 2026
