What is the difference between proto2 and proto3?
Understand proto2 vs proto3: removed required fields, implicit defaults, field presence and the optional keyword, with clear examples for gRPC services.
Expected Interview Answer
proto3 is a simplified, more portable revision of the Protocol Buffers language: it drops required/optional field labels, removes custom default values, and makes all scalar fields carry an implicit zero default, whereas proto2 kept explicit field presence, required fields, and configurable defaults.
In proto2 every field is labelled required, optional, or repeated, and you can set custom defaults and detect whether a field was explicitly set. proto3 removed required (a notorious source of breakage), made scalars behave as if optional with a fixed zero/empty default, and improved support across languages like JavaScript, Go, and Dart. Later proto3 reintroduced the optional keyword to restore explicit field presence when you truly need to distinguish unset from zero.
- Simpler, less error-prone schema language
- Better cross-language and JSON mapping support in proto3
- No fragile required fields that break forward compatibility
- Explicit presence still available via proto3 optional
- Cleaner defaults reduce ambiguity for most services
AI Mentor Explanation
proto2 is like an old team sheet where each slot is stamped 'must field a wicketkeeper' and 'may field a twelfth man', so a missing keeper voids the sheet. proto3 is the modern sheet: no slot is mandatory, an unlisted player simply counts as absent, and the umpires accept it without rejecting the whole line-up over one blank box.
Step-by-Step Explanation
Step 1
Field labels
proto2 uses required/optional/repeated; proto3 drops required and treats scalars as implicitly optional.
Step 2
Default values
proto2 allows custom defaults per field; proto3 fixes defaults to the type's zero/empty value.
Step 3
Field presence
proto2 always tracks whether a field was set; proto3 lost this for scalars but restored it via the optional keyword.
Step 4
Language & JSON support
proto3 added cleaner mappings for JSON, JavaScript, Go, Dart and more.
Step 5
Migration
Choose proto3 for new services; keep proto2 only where explicit presence or custom defaults are essential.
What Interviewer Expects
- Awareness that required was removed in proto3
- Understanding of implicit zero defaults
- Knowledge that proto3 reintroduced optional for presence
- Ability to explain forward/backward compatibility impact
- A sensible recommendation for new services
Common Mistakes
- Claiming proto3 still supports required fields
- Saying proto3 allows custom default values
- Confusing field presence with default values
- Not knowing optional was added back to proto3
Best Answer (HR Friendly)
“proto2 and proto3 are two versions of how you write Protocol Buffer message formats. proto3 is the newer, simpler version that removed strict required fields and confusing custom defaults, making it easier to evolve services and work across many programming languages.”
Code Example
// proto2
syntax = "proto2";
message User {
required string name = 1;
optional int32 age = 2 [default = 18];
}
// proto3
syntax = "proto3";
message User {
string name = 1; // no required, implicit "" default
optional int32 age = 2; // optional restores explicit presence
}Follow-up Questions
- Why was the required field label removed in proto3?
- How do you detect field presence for scalars in proto3?
- How does Protocol Buffers ensure backward compatibility?
- What happens to unknown fields during deserialization?
- When would you still choose proto2 today?
MCQ Practice
1. Which field label was removed in proto3?
proto3 removed the required label because required fields break forward and backward compatibility when schemas evolve.
2. In proto3, an unset scalar int32 field returns what value?
proto3 scalars have an implicit default equal to the type's zero value, so an unset int32 reads as 0.
3. How does proto3 let you distinguish an unset field from a zero value?
proto3 reintroduced the optional keyword to add explicit field presence tracking for scalar fields.
Flash Cards
Did proto3 keep required fields? — No. proto3 removed required entirely; use optional for explicit presence.
proto3 default for an unset string? — Empty string "" — the type's implicit zero value.
Custom default values in proto3? — Not supported; defaults are fixed to zero/empty per type.
Why remove required? — Required fields make schema evolution fragile and break compatibility.
Continue Learning
Related Interview Questions
What is gRPC-Web and how does it enable browser clients?
medium
How do you add values to a protobuf enum without breaking existing clients?
hard
How do you model field presence in proto3 using optional, oneof and wrappers?
medium
How do you version a gRPC API when a change cannot be made backward compatible?
hard