gRPC & Protobuf

APIs

HTTP semantics, retries, idempotency, GraphQL tradeoffs, and contract design.

• gRPC & Protobuf

  6 studies
  1. 1.gRPC & Protobuf — Contracts, Streaming & API EvolutiongRPC is HTTP/2 + Protocol Buffers + generated stubs: a contract-first RPC stack for service-to-service calls. Interviewers care less about binary speed and more about contracts, streaming shapes, evolution rules, and when gRPC is the wrong tool (browsers without grpc-web, public REST ecosystems). This hub maps the cluster: schemas, unary vs streaming, deadlines/errors, load balancing/channels, and the REST/GraphQL decision matrix.
  2. 2.Protobuf Schemas — Fields, Wire Types & CompatibilityProtobuf's wire identity is the field number, not the field name. Types, optional / repeated / map, proto3 defaults, reserved, and wire types determine whether two binaries can talk forever. Interviewers probe: can you add a field safely? Why never reuse numbers? What goes wrong with JSON mapping?
  3. 3.Unary vs Streaming RPCs — Client, Server, Bidi & BackpressuregRPC RPCs are not only request/response. Four shapes — unary, server-streaming, client-streaming, bidirectional — change memory, latency, and failure modes. Senior interviews ask when each fits, how HTTP/2 flow control provides backpressure, and which anti-patterns (unbounded server streams, ignoring cancel) blow up production.
  4. 4.gRPC Deadlines, Cancellation & Error ModelgRPC calls carry a deadline (absolute time), not only a per-hop timeout. Cancellation propagates so servers stop work the client no longer needs. Errors are status codes + optional details + trailers, not HTTP status alone. Interviewers compare this to HTTP codes and ask which statuses are retryable.
  5. 5.gRPC Load Balancing, Name Resolution & Channel HealthgRPC clients open a channel to a resolved set of addresses and may balance RPCs client-side (pick_first, round_robin, …) or through a proxy (Envoy/L7). Name resolution (DNS, xDS), keepalive, health checks, and sticky affinity for bidi decide whether streams survive deploys. Cross-link the general Load Balancing cluster — here we focus on gRPC-specific channel behavior.
  6. 6.gRPC vs REST/JSON & GraphQL — When to Choose WhatThere is no universal winner. Choose gRPC for internal typed service meshes and streaming; REST/JSON for public, cacheable, browser-native HTTP; GraphQL when many clients need flexible graphs of data from a BFF. Honest senior answers include when REST wins — not only when binary RPC looks faster on a whiteboard.