Learn the vocabulary of a compact, schema-driven binary wire format faster than JSON.
0 / 5 completed
1 / 5
At standup, a dev mentions a binary serialization format defined by a compact schema file, producing much smaller messages and faster parsing than a text-based format like JSON. What is this serialization format called?
Protocol Buffers, or Protobuf, is a binary serialization format defined by a compact .proto schema file, producing messages that are both much smaller on the wire and faster to parse than an equivalent JSON payload, since the schema lets both sides skip the overhead of parsing field names as text. GraphQL is a query language for fetching data over an API, which is an unrelated layer from the wire format used to serialize an individual message's fields. This compactness and parsing speed is why Protobuf is a common choice for high-throughput internal service communication.
2 / 5
During a design review, the team assigns each field in a .proto schema a unique, permanent number and commits to never reusing a retired field's number for a different field later. Which capability does this practice protect?
This practice protects backward and forward compatibility across schema versions, since Protobuf identifies a field by its number on the wire, not by its name, so reusing a retired field's number for an unrelated new field would make an old message's bytes get misinterpreted as the new field once both schema versions are in use simultaneously. Protobuf's binary wire format is not human-readable at all without the schema to interpret it, unlike a text-based format like JSON. This numbering discipline is exactly what lets services running different versions of a schema keep communicating correctly with each other.
3 / 5
In a code review, a dev notices a .proto schema change that reuses field number 5, previously retired from an old, now-unused field, for a completely different new field with a different type. What does this represent?
This is a dangerous field-number reuse risking a wire-format collision with any client still holding the old schema, since that older client would interpret bytes intended for the new field as if they belonged to the old, retired field it still remembers by that same number. A schema registry is a related but distinct service for validating and versioning a schema, not the specific numbering mistake itself. Catching this reuse in review matters because the resulting corruption often doesn't surface as an obvious crash, but as subtly wrong data being silently misinterpreted.
4 / 5
An incident report shows data was silently corrupted between two services after a schema change reused a retired field's number for a new field with an incompatible type, and an older client misinterpreted the new field's bytes as the old one. What practice would prevent this?
Never reusing a retired field's number, and always assigning a brand-new number to any new field instead, eliminates the exact wire-format collision that let an older client misinterpret the new field's bytes as the old, retired one. Continuing to reuse retired numbers whenever convenient is exactly what caused the silent data corruption described in this incident. This never-reuse discipline is a well-documented, mandatory rule for evolving a Protobuf schema safely across multiple deployed versions.
5 / 5
During a PR review, a teammate asks why the team chose Protobuf over JSON for a high-throughput internal service, given that JSON is simpler to read and debug directly. What is the reasoning?
JSON's text-based, self-describing format is genuinely easier to read directly during debugging, since a person can open a JSON payload and understand it without consulting a schema. But that same text-based approach costs more in both message size and parsing time compared to Protobuf's compact binary format, which matters a great deal once message volume gets high enough for that overhead to add up. The tradeoff is exactly that debuggability, which JSON offers more readily, against the raw throughput and efficiency Protobuf provides at scale.