gRPC and Protobuf: multiple-choice review
Multiple-choice synthesis across the gRPC/Protobuf unit — field-number compatibility, schema evolution, streaming shapes, deadlines, and the gRPC-vs-REST edge decision.
Six questions that cut across the whole unit. Each mirrors a real decision — a schema change you have to sign off, a streaming shape to pick, a deadline to set — not a definition to recite. The wire carries numbers, not names, and most of these traps spring from forgetting that.
Confirm you can connect the protobuf wire format, field-number discipline, the four call shapes, deadlines, and the gRPC-vs-REST boundary — the synthesis the lesson built toward.
A teammate renames a protobuf field from discount_pct to discountPercent and, in the same commit, renumbers it from 3 to 4 to keep numbers contiguous. Which change is safe and which corrupts data?
You need to remove an obsolete field number 3 from a message that is live in production. What is the senior move?
A new producer build adds field 7 and sends it to consumers still running the old schema; meanwhile an old producer omits field 7 entirely when talking to new consumers. What happens in each direction?
A dashboard needs the server to push live price updates to each client for as long as the client stays subscribed, with no per-update request from the client. Which RPC shape fits, and what is the common mistake?
A client call returns DEADLINE_EXCEEDED, yet the server logs show the handler completed and committed a write. How do you read this, and what is the durable fix?
A public REST endpoint hit directly from a React SPA is slow under load. A teammate proposes converting it to native gRPC so the browser calls it directly. What is the senior call?
The unit’s through-line is one fact: the wire carries field numbers and values, never names. That makes renaming free and renumbering or reusing a number a silent corruption; add-only evolution with reserved is the only safe path, and it is exactly what gives protobuf two-way backward/forward compatibility. On top of HTTP/2 multiplexing, the four call shapes map to who streams (unary, server, client, bidi), deadlines propagate and can fail a caller whose work actually succeeded, and the edge decision stays the same: gRPC between your services, REST/JSON or Connect-RPC at the browser. Now when you see a teammate’s diff that renumbers a field or proposes native gRPC for a browser endpoint, you have the exact words to explain why it won’t work.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.