Interview prompt
Problem context
Skills being evaluated
Use the sequence below to surface constraints, choose boundaries, test failure behavior, and defend trade-offs. Concrete numbers are interview assumptions, not claims about a real production system.
Clarify the decision
- Define framing, semantics, authentication, error, flow-control, and ordering changes. Identify the oldest client lifetime, proxy behavior, and whether a downgrade is ever acceptable.
Establish scale assumptions
- Inventory connections and versions, handshake rate, regional skew, payload shapes, and long-lived session duration. Size servers to run both codecs during the overlap.
Functional and non-functional requirements
- Clients and servers interoperate across adjacent versions, negotiation resists downgrade, rollouts are observable and reversible, and old protocol removal follows actual zero use.
High-level architecture
- Use an explicit version and capability handshake, separate codec from canonical operation logic, and support a bounded compatibility matrix. Gate new features on negotiated capability rather than deployment assumptions.
Data model and flow
- The handshake authenticates peers, exchanges supported versions and capabilities, selects the highest policy-approved mode, and records the choice. Messages use versioned envelopes and unknown-field rules.
Consistency and transaction boundaries
- Operation idempotency and ordering remain stable across codecs. If semantics change, expose a new capability and response contract rather than translating ambiguously.
Failure modes and recovery
- Canary servers accept old and new, clients fall back only within security policy, and connection drains handle long-lived sessions. Malformed new frames isolate connections and cannot exhaust shared parsers.
Security and privacy
- Cryptographically bind negotiation to the authenticated session, prohibit silent insecure downgrade, fuzz parsers, and retire weak credentials before removing the old codec.
Observability and SLOs
- Track negotiated version, downgrade reason, parse errors, feature use, client identity, connection age, and old-protocol traffic. Alert on unexpected fallback after rollout.
Capacity and cost
- Dual codecs increase memory, binary size, test matrix, and on-call complexity; time-box the overlap. Embedded exceptions may require a dedicated gateway rather than permanent server complexity.
Alternatives and trade-offs
- Transparent proxies ease legacy support but can hide semantic differences and become permanent. Use them for isolated slow clients with explicit sunset and telemetry.
Evolution and migration
- Ship dual-stack servers, new clients negotiating old semantics, enable new capability by cohort, make new default, block new old-client registrations, then remove old support after zero-use proof.
What Staff and Principal candidates should emphasize
- Principal candidates version semantics and security, not only bytes. They cover long-lived sessions, downgrade attacks, compatibility matrices, and exceptional clients.
Decision trade-offs
Compatibility
Option A
Teach every server both protocols indefinitely
Option B
Bounded dual stack plus legacy gateway
Recommendation:Keep core dual stack only through the normal migration window; isolate rare long-lived clients behind a measurable gateway.
Fallback
Option A
Automatically use any mutually supported version
Option B
Use highest policy-approved secure version
Recommendation:Bind negotiation to security policy so an attacker or misconfiguration cannot force a vulnerable downgrade.
Follow-up interview questions
- 01How are long-lived connections upgraded?
- 02What prevents a downgrade attack?
- 03What if the protocol changes operation semantics?
- 04When can the old parser be removed?
Common weak answers and mistakes
- 01Adding a version byte without capability and semantic rules.
- 02Allowing silent fallback to an insecure version.
- 03Assuming rolling deploys close long-lived connections quickly.
- 04Keeping dual protocol support forever for one unknown client.
Interviewer evaluation rubric
Runs old and new ports but cannot define negotiation, semantics, security, mixed versions, or removal.
Uses explicit handshake, bounded compatibility, canonical operations, telemetry, canaries, and connection drain.
Adds authenticated downgrade policy, semantic capabilities, parser isolation, legacy gateway, and zero-use gates.
Designs a long-lived protocol evolution discipline that keeps future migrations cheap and security posture monotonic.