gRPC's four RPC patterns each correspond to a common use case. Picking the right one upfront avoids re-architecting later: server-streaming becomes painful when you actually needed client-streaming.
Advertisement
Unary — request-response
One in, one out. Most RPCs. Easy to reason about, easy to retry. 90% of gRPC calls should be unary unless there's a reason not to.
Server / client streaming
Server: one request, many responses (subscriptions, large result sets). Client: many requests, one response (uploads, batch operations). Pick by direction of flow.
Advertisement
Bidirectional streaming
Both sides send independently. Game state sync, voice/video, real-time collaboration. Hard to design well: ordering, backpressure, reconnect. Don't reach for it unless unary or one-direction streaming doesn't fit.
Unary by default. Server-streaming for subscriptions. Bidi only when both sides really push.