What are the four gRPC method kinds, and which one fits a device that uploads a sample every few seconds for hours?
answer
- two sides, one or many each
- two binary choices, four shapes
- one request, many responses
- many requests, one response
- sequence in both directions
basics
~10 sgRPC methods come in four kinds: unary (one request, one response), server-streaming (one request, many responses), client-streaming (many requests, one response) and bidirectional streaming. A device uploading samples for hours fits client-streaming.
solid answer
~40 sEvery gRPC method is exactly one of four kinds, decided by whether each side sends a single message or a sequence. **Unary** is one request and one response. **Server-streaming** is one request and a sequence of responses. **Client-streaming** is a sequence of requests and a single response. **Bidirectional streaming** is a sequence in each direction. The generated method signature follows: a streaming direction shows up as a sequence you write into or read from rather than a single value. A harvester pushing a yield sample every few seconds for six hours and wanting one summary at the end is client-streaming — and all of it is *one call*, with one status at the end, not thousands of calls.
code
pseudocode · 13 lines// the four generated method shapes, one per method kind
registerMachine(request: Machine) returns Receipt
// unary: one message each way
readYieldMap(request: FieldQuery) returns sequence of MapTile
// server-streaming: one request, many responses
uploadRun(requests: sequence of Sample) returns RunSummary
// client-streaming: many requests, one response
liveRun(requests: sequence of Sample) returns sequence of Correction
// bidirectional: a sequence in each directiongo deeper
Be able to name all four kinds and say which side streams in each. Then pick one for a described data flow and justify it in a sentence — that is the whole question at this level.
Explain that a streaming call is one call with one outcome at the end, and that the generated signature turns a streaming direction into a sequence you write into or read from rather than a single value.
Show that you choose the kind from the shape of the data flow, and that you know what a long-lived call costs: a handler occupied for hours, and a call that dies with the server instance holding it.
The angle here is where a long call belongs in a system's failure budget at all: a trickle of short calls and one call held open for six hours fail in different ways, and only one of them survives a routine restart.
gRPC methods come in exactly four kinds. The kind is decided by one question asked twice: does the client send a single message or a sequence, and does the server answer with a single message or a sequence? Two binary choices give four shapes, and every method a service declares is exactly one of them. The kind is fixed at declaration time — a caller cannot turn a unary method into a streaming one at the call site. ## The four kinds - **Unary** — the client sends one message, the server answers with one message. This is the shape that reads like an ordinary function call, and it is still the most common one in practice. - **Server-streaming** — the client sends one message, the server answers with a sequence of messages of any length, then ends the call. - **Client-streaming** — the client sends a sequence of messages, the server answers with a single message once that sequence is finished. - **Bidirectional streaming** — both sides send sequences, and neither sequence has to wait on the other. | Kind | Client sends | Server sends | What the generated method gives the caller | |---|---|---|---| | Unary | one message | one message | a request argument, one response value | | Server-streaming | one message | many messages | a request argument, a readable sequence | | Client-streaming | many messages | one message | a writable sequence, one response value | | Bidirectional | many messages | many messages | a writable sequence and a readable sequence | The last column is the practical difference at the call site. A streaming direction is not a bigger message; it is a sequence you write into or read from over time, and the generated signature says so. ## A streaming call is one call The most common misreading is that a streaming method is a convenience wrapper over many calls. It is not. Everything in a streaming call happens inside a **single call**: one call beginning, one sequence of messages in each streaming direction, and exactly **one status at the end** that reports the outcome of the whole thing. Five thousand yield samples uploaded on a client-streaming method are five thousand messages inside one call — not five thousand calls. Two consequences follow immediately: 1. A failure partway through does not fail "one of the messages". It fails the call, and every message already sent belongs to a call that ended badly. 2. The protocol defines **no per-message acknowledgement**. If the application wants one, it has to be a message travelling in the other direction — which means the method kind must *have* another direction, and that is bidirectional streaming. ## Picking a kind for the harvester - The machine samples yield every few metres for six hours and the back office replies once, at the end, with a run summary → **client-streaming**. - The machine sends samples *and* wants calibration corrections back while it is still cutting → **bidirectional streaming**. - The office asks for a finished field's yield map and the server produces it row by row → **server-streaming**. - The machine registers itself, or reports that a run has started → **unary**. Notice that the choice is driven by the *shape of the data flow*, not by how much data there is. A large payload that is ready all at once can still be a unary response; a small trickle produced over hours cannot honestly be one. ## Why not call a unary method in a loop A loop of unary calls is a legitimate design and sometimes the right one, but it is a different design, not the same one written differently. Each iteration is an independent call with its own beginning, its own outcome and its own per-call overhead, and nothing ties the sequence together — the server sees unrelated calls and has to correlate them itself from something in the messages. A single streaming call gives the server one handler invocation that sees the whole sequence in order, and gives the client one outcome to handle instead of thousands. ## What a streaming kind costs - The call is long-lived, so it occupies a server-side handler for its entire life rather than for a few milliseconds. - It ends when that server instance goes away — a restart ends every call in flight, where a loop of short calls simply continues against whatever instance answers next. - One deadline covers the whole call, so the bound has to be sized for the *whole* sequence and not for one message. Naming the four kinds is a first-screen question. Knowing that a stream is one call with one outcome is what the interviewer is actually listening for.
- Is a server-streaming gRPC call many calls or one?One. The whole sequence of response messages lives inside a single call: one beginning, many messages, and exactly one status at the end that reports the outcome of the entire call. The messages are not individually acknowledged and they do not have individual outcomes — if the call fails halfway through, it is the call that failed.
- The harvester must also receive calibration corrections while it is still uploading samples. Which kind now?Bidirectional streaming. Client-streaming gives the server exactly one message to send, and it can only send it once the client's sequence is finished, so corrections could not arrive mid-run. Bidirectional gives each side its own sequence, so the office can send a correction at any point while samples are still arriving.
- Can the same service mix kinds?Yes — the kind is a property of each method, not of the service or the connection. A service can declare a unary registration method, a client-streaming upload and a bidirectional live session side by side, and calls of all three kinds run concurrently over the same connection.
Posting one letter and getting one back, subscribing to a newsletter, mailing a stack of forms and getting one receipt, or holding a correspondence where either side writes whenever it likes.
saying these in an interview costs you the question
- Says gRPC only does request and response, like a plain HTTP API
- Treats every streamed message as its own call with its own outcome
- Picks server-streaming for a job where the client is the sender
- Thinks a streaming method needs a new connection per message
- Assumes the four kinds differ only in payload size