Community Question Bundle
gRPC vs REST Tradeoff Quiz
A 4-question reference set comparing gRPC and REST on the dimensions that matter at interview time: latency overhead, call types, schema evolution, and observability. Pick the right tool for the workload.
gRPC vs REST Tradeoff Quiz
A 4-question reference set comparing gRPC and REST on the dimensions that matter at interview time: latency overhead, call types, schema evolution, and observability. Pick the right tool for the workload.
By CodeSnatch
April 8, 2026
·
Updated May 18, 2026
473 views
12
4.3 (12)
gRPC uses HTTP/2 with binary protobuf framing; REST commonly uses HTTP/1.1 with JSON. List the latency-relevant differences and pick the right pick for a request/reply API with strict p99 budgets.
Examples
Example 1:
Input: Service-to-service call with 5KB request, 5KB response, 200 RPS, p99 budget 30ms
Output: gRPC fits well; protobuf encode+decode + HPACK header compression saves 5-15ms vs JSON over HTTP/1.1
Explanation: Binary framing, header compression, and persistent multiplexed streams reduce overhead per call.Example 2:
Input: Public web API consumed by browsers and curl scripts
Output: REST + JSON wins on debuggability and zero-tooling clients, even at slightly higher latency
Explanation: gRPC-Web exists but adds proxy complexity; REST has near-universal client support out of the box.gRPC has four call types: unary, server streaming, client streaming, and bidirectional streaming. Match each to a real workload and explain which one REST cannot replicate cleanly.
Examples
Example 1:
Input: Server pushes 100MB of analytics events to client as they happen
Output: Server streaming. REST equivalent is Server-Sent Events; works but lacks gRPC's flow control.
Explanation: gRPC reuses HTTP/2 flow control so a slow consumer naturally backpressures the producer.Example 2:
Input: Two services chat back and forth (e.g. chat or game state sync) over a long-lived connection
Output: Bidirectional streaming. REST has no clean equivalent without WebSockets or polling.
Explanation: Bidi streaming is the gRPC pattern that has no direct REST analog; it is the strongest argument for gRPC.Protobuf is schema-first; JSON is schema-by-convention. Walk through what happens when a server adds a new optional field and a client built against the old schema receives the new payload.
Examples
Example 1:
Input: Server adds field 7 'created_by' (optional string) to User message
Old client parses response with field 7 present
Output: Old client silently ignores field 7; existing fields decode normally
Explanation: Protobuf wire format is tag-length-value; unknown tags are skipped by the decoder.Example 2:
Input: Server removes field 3 'email' and reuses tag 3 for a new field 'phone'
Output: Old client decodes 'phone' bytes as 'email' bytes -> garbage data
Explanation: Tag numbers are the contract; reusing one breaks backward compatibility.REST sometimes wins on observability because every call has a stable URL path. What is the gRPC equivalent for path-based monitoring, and where does it fall short of HTTP-method-and-path slicing?
Examples
Example 1:
Input: gRPC server, want per-RPC latency histogram in Prometheus
Output: Use grpc_server_handled_total{grpc_method,grpc_service} and grpc_server_handling_seconds histogram
Explanation: Service+method is the gRPC equivalent of HTTP method+path; both are stable cardinality.Example 2:
Input: REST URL contains a path parameter (GET /users/{id}/orders/{order_id})
Output: Cardinality explosion in metrics unless you normalize the path before recording
Explanation: gRPC has no path params (the parameters are in the protobuf body), so this class of mistake is gone.