LearnThatStack Ace your next interview
API Design · question
Question 18 of 110

What types of service methods does gRPC support?

beginner
← All API Design questions
Re-explain

gRPC supports four types of service methods:

  1. Unary RPC: Client sends one request, server returns one response
rpc GetUser(UserRequest) returns (User);
  1. Server Streaming RPC: Client sends one request, server returns a stream of responses
rpc ListUsers(ListUsersRequest) returns (stream User);
  1. Client Streaming RPC: Client sends a stream of requests, server returns one response
rpc CreateUsers(stream User) returns (CreateUsersResponse);
  1. Bidirectional Streaming RPC: Both client and server send streams of messages
rpc Chat(stream ChatMessage) returns (stream ChatMessage);
Rewriting in plainer words…

This answer doesn't lend itself to a diagram - it reads best . No credits were charged.

Why there's no diagram: “”

The interactive diagram is below the answer - jump to diagram ↓ · Below it, the related concept . Jump to it ↓

The diagram below the answer is the concept . Jump to it ↓

Tailored explanation · switch back to · ·
What should the new diagram focus on?
Guided practice for API Design One question at a time. Answer out loud, get graded, see what you missed.
How well did you know this?
AI:

Saved in this browser - sign in to keep your review list.

How should your speech become text?

Listening… your words appear above as you speak - tap Stop when you're done.

Recording · cr - tap Stop & transcribe when you're done.

Transcribing with AI…

Voice:

Keep going - a few more words and AI can grade it.

Interview lens How interviewers actually use this question

Likely follow-ups

  • When would you use server streaming instead of paging through results with repeated unary calls? Streaming sends rows as soon as they're ready. Paged unary calls are easier to retry, cache and resume after a failure. Say which one your case needs.
  • Give a real use case for client streaming. Why not just send one big request? Think chunked file uploads or batched sensor readings. The client sends pieces as they're ready, and a single message has a size limit.
  • What happens when the client reads a server stream slower than the server writes? HTTP/2 flow control fills the window and the server's writes stall. The handler should wait on that, not buffer without limit in memory.
  • How does a stream end, and how does the client learn it failed halfway through? The server closes with a status code in the trailers. Messages already received still count, so the client must handle a partial result or resume.
  • Which of the four method types can a browser call through gRPC-Web? Unary and server streaming work. Client and bidirectional streaming don't, so a chat feature in the browser needs another transport like WebSockets.

What you can say

  1. gRPC has four method types, and the only difference is where the stream keyword goes in the .proto: on the request, the response, both, or neither.
  2. Unary is the plain case, one request and one response, like GetUser returning a User, and it's what most methods should be.
  3. Server streaming takes one request and sends back a stream, like ListUsers sending users one at a time instead of one giant list.
  4. Client streaming flips that. The client sends a stream, like CreateUsers, and the server answers once with a single response.
  5. Bidirectional streaming lets both sides send streams over the same call, each at its own pace, which fits something like chat.
  6. Streaming has a cost. Long-lived calls are harder to load balance, retry and debug, so I default to unary and stream only when data arrives over time.

Weak answers to avoid

  • Lists 'unary, streaming, bidi' and stops That drops client streaming and hides the direction. Name all four by who sends many messages: the client, the server, both, or neither.
  • Treats streaming as the faster choice Long-lived streams are harder to load balance, retry and debug. Say streaming fits data that arrives over time, and unary stays the default.
  • Describes bidi as request, reply, request, reply The two streams are independent. Each side reads and writes at its own pace, and the server doesn't have to answer every message in turn.
  • Gives definitions with no use case Bare definitions sound memorized. Tie each type to a case: fetch one record, feed a long result list, upload chunks, run a chat.
Interview lens

Likely follow-ups, what you can say, and the weak answers to avoid.

Sign in free to open it Free account - the lens opens as soon as you're back.

Want a quick review of the fundamentals? See the API Design cheatsheet.

← Back to all API Design questions
Pro · $10/mo

90 of 110 API Design answers are in Pro.

Full answers, code samples, and AI explanations that go simpler or deeper. Cancel anytime.

  • Full answers + code
  • AI explanations, simpler or deeper
  • 1,000 AI credits / month
  • Cancel anytime