gRPC Service Types — Unary, Server Streaming, Client Streaming, Bidirectional

gRPC gives you four RPC patterns built on HTTP/2 streaming, and the stream keyword in the .proto file controls which one you get. Each pattern suits different communication needs.

Unary — the default for most calls:

• One request, one response — exactly like REST; use it for 90% of service calls including lookups, CRUD operations, and anything request-response
• The simplest lifecycle: call the method, get a result, done; no streaming complexity or cancellation management required

Server streaming — replacing polling:

• The client sends one request and the server pushes a stream of responses — live order tracking, log tailing, streaming large query results
• Instead of clients polling every 2 seconds with full request overhead each time, the server pushes updates on a single connection at any rate; the single connection eliminates repeated TLS and HTTP setup costs

Client streaming:

• The client sends a sequence of messages and gets one response at the end; natural for chunked file uploads and telemetry batching where you send many small pieces and get a summary confirmation

Bidirectional streaming:

• Both sides push independently over a full-duplex channel; chat applications, collaborative editing, and trading feeds with acknowledgments all use this pattern
• The most complex lifecycle: both sides can send or close at any time, so error handling and cancellation require careful design

Lifecycle safety rules:

• onError and onCompleted are both terminal on StreamObserver — call either twice and you get IllegalStateException
• Always check Context.current().isCancelled() in server-streaming loops or you'll keep producing data for disconnected clients

I recommend starting with unary and only adding streaming when polling overhead or per-call latency is a measured problem, not a theoretical one — streaming adds real lifecycle complexity.