Build a gRPC-style RPC framework (14 scenes)
Scene 12 · Design canvas: configure the RPC stack
Pick codec, transport, deadline, retry, balancing, and security for four named workloads — each defended by the scene that taught it. gRPC inside the fleet, REST at the edge.
Previously
Every name you earned — length-prefix, field number, stream, deadline, cancellation, idempotency, interceptor, client-side LB, flow control, QUIC, mTLS — is now a knob; the last move is to set them coherently for a concrete workload and defend each choice with the scene that taught it.
Scene 12
Design canvas: configure the RPC stack
Diagram
Four workload cards on the left, each a row of knob chips: codec (protobuf vs JSON, scene 3), transport (HTTP/2 vs HTTP/3-QUIC, scenes 4 & 10a), call shape (unary vs streaming, scene 5), deadline (loose vs tight, scene 6), retry (off vs budgeted token-bucket, with an idempotency flag, scene 7), load balancing (L4 vs client-side round-robin, scene 9), and security (TLS vs mTLS, scene 11). The verifier on the right grades the selected card's choices and cites the scene each one traces back to.
This is the whole curriculum on one canvas. Each workload card carries a row of knobs, and every knob is a term you already own — codec, transport, call shape, deadline, retry, load balancing, security. The telemetry card (C) just loaded a preset of unary, loose deadline, and raw unbudgeted retries on a non-idempotent method. Watch the verifier flash red: it cites scene 5 (a never-ending flow should be a streaming call), scene 10 (no stream means no backpressure — the producer can OOM), and scene 7 (raw retries on a non-idempotent method are unsafe). The verifier never just says 'wrong' — it names the scene that taught you why.
Not sure what to ask? Tap a question — the staff engineer answers in the chat panel.