APIs
gRPC and Protobuf: multiple-choice review
Crux Multiple-choice synthesis across the gRPC/Protobuf unit — field-number compatibility, schema evolution, streaming shapes, deadlines, and the gRPC-vs-REST edge decision.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix 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.
Goal
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.
Quiz
Completed
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?
Heads-up Protobuf serializes only field number, wire type, and value — names live in the .proto at compile time and never travel. The number is the identity, so renumbering reassigns meaning on the wire.
Heads-up There is no string key on the wire. Renaming changes only a local source-code label; old and new binaries interoperate perfectly across a rename.
Heads-up Recompiling does not help: each side compiles a self-consistent schema, so the compiler never sees the conflict. Stragglers on the old number are the ones that corrupt.
Quiz
Completed
You need to remove an obsolete field number 3 from a message that is live in production. What is the senior move?
Heads-up The compiler only checks the current file's self-consistency. A later innocent edit can reassign 3 to a new field, and old clients still sending the original field 3 will poison it. reserved is what blocks that.
Heads-up Renumbering is exactly the catastrophe to avoid — peers on the old schema decode values into the wrong fields. Gaps in numbering are completely fine and cost nothing on the wire.
Heads-up Type changes do not make removal safe and can themselves break wire compatibility. The issue is the number's identity, which only reserved protects.
Quiz
Completed
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?
Heads-up Protobuf is built for partial matches: unknown fields are skipped, missing fields default. Strict exact-match rejection would make independent deployment impossible.
Heads-up Unknown field numbers are skipped using their wire type to know their length — and preserved for re-serialization. No crash; this is forward compatibility.
Heads-up proto3 has well-defined zero defaults (0, empty string, false, empty) for missing scalar fields — there is no null for them. Message fields are the exception, exposed via presence.
Quiz
Completed
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?
Heads-up Polling reintroduces the request-per-update overhead that server streaming exists to eliminate, and adds latency equal to the poll interval. Server streaming pushes as data is ready over one open stream.
Heads-up That is the inverse of what is needed. Client streaming suits uploads/telemetry batching; here the server is the one producing the stream.
Heads-up Server streaming already pushes a response stream from one request. Bidi is for when both sides stream independently (chat, control channels); using it here is over-engineering.
Quiz
Completed
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?
Heads-up A deadline cancels the RPC on both ends, but it cannot un-run work already in flight on the server. A succeeded-server / failed-client outcome is the classic deadline race.
Heads-up Deadlines propagate as a relative duration in metadata, not an absolute wall-clock time, so clock skew is not the cause. The cause is the response losing the race to the deadline.
Heads-up Dropping deadlines is how a mesh cascades into resource exhaustion — slow downstreams pin callers forever. The fix is idempotency plus realistic deadlines, not removing them.
Quiz
Completed
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?
Heads-up Browsers cannot make native gRPC calls at all. You would be forced into grpc-web and a proxy hop, lose readable payloads in DevTools, and gain little if the payload is string-heavy.
Heads-up Edge and internal tiers have opposite constraints. Forcing one protocol drags the proxy requirement and binary opacity to the browser, where they cost most, for uniformity you do not need.
Heads-up That throws away the typed contract and schema-evolution guarantees that are gRPC's whole point, and reinvents framing, deadlines, and backpressure by hand — usually worse than either option.
Recap
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.