Explain gRPC Streaming vs Unary Calls.
A unary gRPC call sends one request and gets one response, like a normal function call over the network. A streaming call keeps the connection open and sends many messages over it. gRPC has four call types: unary, server streaming, client streaming, and bidirectional streaming.
Use unary for ordinary operations such as fetching a profile or creating a record. Use streaming when one side has many messages to send over time, or when the result arrives in pieces.
The four gRPC call types
| Call type | Request | Response | Typical use |
|---|---|---|---|
| Unary | One message | One message | Get a user, create an order, log in |
| Server streaming | One message | Many messages | Large result sets, live price feeds, log tails |
| Client streaming | Many messages | One message | File upload in chunks, batched sensor readings |
| Bidirectional | Many messages | Many messages | Chat, collaborative editing, voice transcription |
All four run over a single HTTP/2 connection. HTTP/2 carries many independent streams at once, so gRPC does not open a new connection per call.
How a unary call behaves
The client sends one message and waits. The server does its work and returns one message plus a status code.
service UserService { rpc GetUser(GetUserRequest) returns (User); }
Unary calls are stateless from the server's point of view. Each one stands alone, so any instance can serve it. That makes load balancing simple. A proxy can send each call to a different backend.
Unary is the right default. Most endpoints in a real service are unary.
How streaming calls behave
A streaming call opens one HTTP/2 stream and keeps it open. Messages flow over that stream until one side closes it.
service PriceService { rpc WatchPrices(WatchRequest) returns (stream PriceUpdate); rpc UploadFile(stream Chunk) returns (UploadResult); rpc Chat(stream ChatMessage) returns (stream ChatMessage); }
The word stream in front of the type is the whole difference in the contract.
Streaming saves the setup cost of repeated calls. It also lets the server push data the client did not ask for again. The cost is that the connection is now stateful. The client stays pinned to one backend instance for the life of the stream.
What streaming changes for your system
Load balancing gets harder. A long stream stays on one backend. If you deploy or scale during that time, some clients keep talking to an old instance until their stream ends. Connection level load balancers cannot rebalance mid stream.
Flow control matters. HTTP/2 has built in backpressure, which means a slow reader can tell the sender to slow down. A fast producer with a slow consumer will fill buffers if you ignore it.
Cleanup is on you. A stream that is never closed holds memory and a connection slot on both sides. Set deadlines on every call, and cancel streams when the work is abandoned.
Errors arrive differently. A unary call fails once, with one status. A stream can deliver 500 good messages and then fail. The client needs to know what it already processed, so design for resume, not just retry.
When to pick each one
Choose unary when the operation has a clear start and end. Use it when the response fits in one message. It also keeps retries and scaling simple.
Choose server streaming when the result is large or open ended. Sending 100,000 rows as one response forces both sides to hold it all in memory. Streaming lets the client process rows as they arrive.
Choose client streaming when the client produces data over time and the server only needs to answer once. Chunked uploads are the common case.
Choose bidirectional when both sides talk at the same time and order matters within each direction. Chat and live transcription fit here.
gRPC compared to REST
This question usually follows the streaming one, so it helps to have a short answer ready.
gRPC uses HTTP/2 and Protocol Buffers, a binary format defined by a schema file. REST usually uses HTTP/1.1 or HTTP/2 with JSON, a text format. Binary messages are smaller and faster to parse, and the schema gives you generated client code in many languages.
REST wins on reach and on tooling. Any browser, any curl command, and any proxy understands it. gRPC needs a proxy layer such as gRPC Web to reach a browser at all.
The usual split is gRPC between internal services, REST at the public edge. Streaming is one of the main reasons teams pick gRPC internally, because REST has no native equivalent that is as cheap.
Common mistakes
- Using streaming for a simple request and response. It adds state for no gain.
- Forgetting to close or cancel a stream, which leaks memory and connections.
- Assuming streaming is always faster. For short calls the setup dominates and unary wins.
- Ignoring deadlines. Every call should carry one, streaming calls most of all.
- Treating a stream failure like a unary failure and replaying the whole thing.
- Putting long lived streams behind a load balancer that cannot handle them.
Frequently asked questions
What is the difference between unary and streaming in gRPC?
Unary sends one request and returns one response. Streaming keeps the connection open so many messages can flow in one or both directions. Unary is stateless and easy to balance. Streaming is stateful and pins the client to one backend.
What are the four types of gRPC calls?
Unary, server streaming, client streaming, and bidirectional streaming. The stream keyword in the .proto file marks which side sends many messages.
Is gRPC streaming faster than unary?
For many messages in a row, yes, because it avoids repeating the call setup. For a single short request, unary is usually faster, since the stream setup is pure overhead.
When should I use gRPC over REST?
Use gRPC for internal service to service traffic where you control both sides, want a strict schema, and need streaming or low latency. Use REST at the public edge, where browser support and familiar tooling matter more.
Does gRPC streaming need WebSockets?
No. gRPC streaming uses HTTP/2 streams directly. WebSockets solve a similar problem for browsers, which is why gRPC Web exists as a bridge.
How do I handle errors in a streaming call?
Treat a partial stream as partial progress. Track what you consumed, then resume from that point rather than starting over. Send a status code and a clear message when you close the stream early.
How to prepare
Design the contract, not just the call. Choosing unary or streaming is a contract decision, and interviewers grade the reasoning. Grokking Modern API Design Interview covers gRPC contract design and the rules for choosing between REST, gRPC, and GraphQL.
Say the trade off out loud. Practice with Mock Interviews with ex-FAANG engineers so the reasoning sounds natural under time pressure.
Related reading
GET YOUR FREE
Coding Questions Catalog
$123
$197
$72
