What is server-side streaming in gRPC?
Server-side streaming in gRPC sends one request and streams many responses. Learn the proto syntax, use cases like live feeds, and how the stream ends.
Expected Interview Answer
Server-side streaming is a gRPC pattern where the client sends a single request and the server responds with a stream of many messages over one long-lived HTTP/2 stream.
It is declared in the .proto with the stream keyword on the response type only: rpc Method(Request) returns (stream Response). The server writes messages one after another as data becomes ready, and the client reads them in order until the server signals completion with a final status. This is ideal when one query produces a large or open-ended set of results — paginated exports, live feeds, progress updates, or search results — that you want to deliver incrementally instead of buffering everything into one giant response.
- Delivers large result sets incrementally without huge buffers
- Lower time-to-first-byte for the client
- Natural fit for live feeds and progress updates
- Ordered, reliable delivery over one HTTP/2 stream
- Supports backpressure, deadlines and cancellation
AI Mentor Explanation
Server-side streaming is like asking for live ball-by-ball commentary of an innings: you make one request — 'follow this match' — and then the commentator sends you a continuous stream of updates, one delivery at a time, until the innings ends. You asked once, but you keep receiving many ordered messages. That single-request, many-responses shape is exactly what a server-streaming gRPC method provides to its client.
Step-by-Step Explanation
Step 1
Declare the stream
In the .proto write rpc ListEvents(EventQuery) returns (stream Event); with stream on the response type only.
Step 2
Generate code
Regenerate stubs so the server handler receives a response stream/writer and the client gets a readable stream.
Step 3
Write messages on the server
Loop over your data source and call stream.Send(msg) for each item as it becomes available.
Step 4
Signal completion
Return from the handler (or close the stream) so gRPC sends the final OK status to the client.
Step 5
Read on the client
Loop calling stream.Recv() until you get io.EOF or an error, processing each message in order.
What Interviewer Expects
- One request, many responses is stated clearly
- Knowing stream sits on the response type only in proto
- Good use cases like feeds, exports and progress
- Understanding of ordered delivery and completion status
- Awareness of backpressure, deadlines and cancellation
Common Mistakes
- Putting the stream keyword on the request side by mistake
- Confusing it with client-side or bidirectional streaming
- Buffering all messages server-side instead of sending incrementally
- Forgetting to close or return so the client never sees EOF
- Assuming messages can arrive out of order
Best Answer (HR Friendly)
“Server-side streaming is when a client asks one question and the server sends back a steady stream of many answers over time, like tuning into live commentary. It is great for delivering large results or live updates bit by bit instead of all at once.”
Code Example
service FeedService {
// One request, a stream of responses
rpc ListEvents(EventQuery) returns (stream Event);
}
message EventQuery {
string topic = 1;
}
message Event {
string id = 1;
string payload = 2;
}func (s *server) ListEvents(q *pb.EventQuery, stream pb.FeedService_ListEventsServer) error {
for _, e := range s.eventsFor(q.Topic) {
if err := stream.Send(&pb.Event{Id: e.ID, Payload: e.Data}); err != nil {
return err
}
}
return nil // returning closes the stream with OK status
}Follow-up Questions
- How does the client know the stream has ended?
- How is backpressure handled in server streaming?
- How do deadlines and cancellation propagate to the server?
- When would you choose server streaming over pagination?
- How does this differ from bidirectional streaming?
MCQ Practice
1. In server-side streaming, how many messages flow each way?
The client sends one request and the server streams many response messages back.
2. Where does the stream keyword go in the proto method?
Server streaming marks only the response with stream: returns (stream Response).
3. Which is a strong use case for server-side streaming?
Delivering large or open-ended result sets incrementally is exactly what server streaming is for.
Flash Cards
What is server-side streaming? — One client request, a stream of many server responses.
Proto syntax? — rpc M(Req) returns (stream Resp);
How does the client detect the end? — Recv() returns io.EOF and a final OK status.
Best use cases? — Live feeds, large exports, and progress updates.