Every system design starts with "how do clients talk to your service?" REST, gRPC, GraphQL, WebSocket, and SSE are not interchangeable — each optimizes for a different communication pattern. Choosing the wrong protocol means re-architecting your API layer when requirements change.
Interviewers use this question to test whether you think about payload efficiency, latency, streaming needs, and client constraints — not just "REST because everyone uses it."
| Protocol | Payload format | Latency | Streaming | Browser support | Best for |
|---|---|---|---|---|---|
| REST | JSON (text, human-readable) | Moderate (HTTP/1.1 overhead, JSON parsing) | No native streaming | Universal | Public APIs, CRUD, broad compatibility |
| gRPC | Protobuf (binary, compact) | Low (HTTP/2 multiplexing, binary serialization) | Bidirectional streaming built-in | Limited (grpc-web proxy needed) | Internal service-to-service, polyglot microservices |
| GraphQL | JSON (client specifies shape) | Variable (depends on resolver complexity) | Subscriptions via WebSocket | Universal (HTTP POST) | Mobile/web with diverse data needs, BFF replacement |
| WebSocket | Any (text or binary frames) | Very low (persistent connection, no HTTP overhead) | Full-duplex bidirectional | Universal | Chat, gaming, collaborative editing, live updates |
| SSE (Server-Sent Events) | Text (UTF-8 event stream) | Low (long-lived HTTP connection) | Server → client only (unidirectional) | Universal (EventSource API) | Live feeds, notifications, dashboards |
Key insight: REST is the lingua franca for external APIs. gRPC wins on efficiency for internal calls. GraphQL solves the over-fetching problem for diverse clients. WebSocket and SSE handle real-time — bidirectional vs unidirectional respectively.
Ask these questions in order during your design:
The interview answer: "REST for public APIs. gRPC for internal service-to-service. GraphQL for flexible client queries. WebSocket for bidirectional real-time."
REST over HTTP/2 is faster than people assume. With gzip/brotli compression and connection multiplexing, the JSON overhead shrinks significantly. REST shines when you need HTTP caching (CDN, browser cache, reverse proxy), hypermedia discovery, and broad tooling support. For 80% of systems, REST is the right default.
Google, Netflix, and Uber use gRPC for internal communication. The protobuf schema acts as an enforced contract between teams. Streaming RPCs (server-streaming, client-streaming, bidirectional) handle patterns that would require WebSocket in REST-land. The main pain point: debugging binary payloads is harder than JSON.
GraphQL solves real problems (over-fetching, under-fetching, API versioning) but introduces new ones: query cost analysis (prevent expensive queries), caching complexity (no HTTP cache by default), and schema governance. Best when you have many client types with different data needs. Overkill for a single client consuming a single backend.
The protocol is simple; the operations are hard. At scale, you need: (1) a pub/sub layer (Redis, Kafka) to fan messages across WebSocket servers, (2) connection state management (which user is on which server), (3) graceful reconnection handling. Load balancers need sticky sessions or connection-aware routing.
SSE is often overlooked in favor of WebSocket, but for server-push-only patterns (notifications, live feeds, progress updates), SSE is simpler: standard HTTP, automatic reconnection, works through most proxies. ChatGPT's streaming response uses SSE. Use it when you don't need the client to send data back over the same connection.
Production systems typically use multiple protocols: REST for the public API gateway + gRPC between internal services + WebSocket for real-time features + SSE for streaming responses. Articulate this layering in interviews.