# Senior gRPC Backend Playbook

Compressed reference for the senior-only gRPC extension. Pair with [cheat-sheet.md](./cheat-sheet.md), [GLOSSARY.md](./GLOSSARY.md), and [repo-grpc-map.md](./repo-grpc-map.md).

## The senior shift
Junior/intermediate gRPC asks: "Can you explain protobuf, the four RPC types, interceptors, status codes, and deadlines?"
Senior gRPC asks: "Can you evolve the contract safely, design retry-safe calls, debug bad behaviour in production, and choose the right boundary between gRPC and REST?"

## The six senior lenses
1. **Contract evolution first** — field numbers and additive changes matter more than pretty proto names.
2. **Retry safety thinking** — retries are only helpful when the RPC semantics are safe enough to retry.
3. **Streaming trade-off honesty** — streaming is powerful, but it raises operational and cancellation complexity.
4. **Budget propagation** — deadlines, cancellation, and retries interact; they are not isolated features.
5. **Debugging from evidence** — trace, metadata, status, interceptor chain, and downstream timing all tell part of the story.
6. **Boundary design** — not every external edge should be native gRPC, even if the internal system is.

## Senior review checklist
- If this proto changes, is it additive or breaking?
- Are any field numbers being reused, removed unsafely, or changed semantically?
- If the client retries, could the server side effect happen twice?
- Should this call stay unary, or is there a real sequence/streaming reason?
- Are deadlines propagated through the whole downstream call tree?
- Would traces and metadata be enough to debug a slow or failed call?
- Does this boundary really want native gRPC, or should a gateway/REST edge own the public interface?

## Interview answer shapes
### Why are field numbers such a big deal?
Because field numbers are the wire identity. Names can change for humans, but reusing or changing the meaning of a field number breaks compatibility.

### Why can retries be dangerous?
Because a retry can repeat a side effect unless the RPC is idempotent or has a deduplication strategy. Retries are a correctness question, not just a resilience feature.

### Why don’t teams use streaming everywhere?
Because streaming increases lifecycle, cancellation, backpressure, and debugging complexity. Unary is often simpler and better unless the data really is a live sequence.

### What is a strong gRPC debugging workflow?
Start with the failing or slow RPC, inspect trace/span evidence, check status/metadata/deadline behaviour, identify which interceptor or downstream hop is involved, then choose the fix based on evidence rather than folklore.

### Why might REST still win at the edge?
Because browsers, third parties, and public APIs often benefit from JSON/HTTP ergonomics, tooling, and compatibility expectations even when the internal service mesh is gRPC.