Protocol Buffers (protobuf) are Google's language-neutral, platform-neutral, extensible mechanism for serializing structured data. gRPC uses protobuf for several reasons:
Efficiency: Binary serialization is faster and more compact than JSON/XML
Type Safety: Strongly typed schema prevents runtime errors
Code Generation: Automatically generates client and server code
Language Agnostic: Works across different programming languages
Schema Evolution: Supports backward and forward compatibility
Example protobuf definition:
syntax = "proto3";
message User {
int32 id = 1;
string name = 2;
string email = 3;
}
service UserService {
rpc GetUser(UserRequest) returns (User);
}
Rewriting in plainer words…
This answer doesn't lend itself to a diagram - it reads best . No credits were charged.
Saved in this browser - sign in to keep your review list.
How should your speech become text?
Listening… your words appear above as you speak - tap Stop when you're done.
Recording · cr - tap Stop & transcribe when you're done.
Transcribing with AI…
Voice:
Keep going - a few more words and AI can grade it.
Interview lens
How interviewers actually use this question
Likely follow-ups
What changes to a .proto file break existing clients, and how do you remove a field safely?Field numbers, not names, go on the wire. Never change or reuse a number, mark removed ones reserved, and know old readers skip unknown fields.
Why is a protobuf message smaller than the same data sent as JSON?Each field is tagged by its number instead of its name, integers use varint encoding, and the reader needs the schema to decode the bytes.
When would you choose JSON over protobuf for an API?Browser clients, public APIs and reading payloads by eye favor JSON. Say what protobuf costs there, like needing gRPC-Web and a shared schema.
In proto3, how do you tell a field that was never set from one set to zero or empty?Scalars default to zero values that are not sent on the wire. Mention the optional keyword or wrapper types for explicit presence.
What you can say
Protocol Buffers are Google's language-neutral format for structured data. You define the data once in a schema, and it serializes to compact binary.
In a .proto file you declare messages with a type and a number for each field, plus services with their RPC methods, and a compiler generates code from that file.
gRPC uses protobuf for a few reasons. The binary encoding is smaller and faster to parse than JSON or XML, and the strong typing catches mismatched data before runtime.
Code generation gives you client and server code in many languages from that one file, so a Go server and a Java client share the same contract.
It also supports backward and forward compatibility, as long as you add fields with new numbers and never reuse the old ones.
The cost is that you can't read the payload by eye and browsers can't call gRPC directly, so for public or browser-facing APIs I'd usually still use JSON.
Weak answers to avoid
Recites the benefit list with no mechanismSaying 'efficient' and 'type safe' sounds memorized. Explain one mechanism, like field numbers replacing field names on the wire.
Thinks field names identify data on the wireThe field number is what gets encoded. Renaming is safe, but changing or reusing a number breaks old clients. Say you reserve removed numbers.
Says gRPC only works with protobufProtobuf is gRPC's default, but gRPC can carry other formats. Say it is the default because of the schema, code generation and compact encoding.
Names no downsideBinary payloads are not human-readable, browsers need gRPC-Web, and every client needs the .proto. Naming one cost shows you know when not to use it.
Interview lens
Likely follow-ups, what you can say, and the weak answers to avoid.
