123 gRPC Interview Questions and Answers (2026)

Over traditional REST, gRPC offers a compact binary protocol, a strict shared contract, native streaming, and multi-language code generation, making it especially strong for internal service communication.

• Performance: Protobuf binary + HTTP/2 multiplexing means smaller payloads and fewer connections than JSON over HTTP/1.1.

• Strong contract: The .proto file is a single source of truth; codegen enforces types and catches mismatches at compile time.

• Streaming: Built-in client, server, and bidirectional streaming, hard to do cleanly in REST.

• Polyglot codegen: Generate consistent clients and servers across many languages automatically.

• Built-in features: Deadlines, cancellation, metadata, and pluggable auth/interceptors come out of the box.

Protocol Buffers are far faster and more compact than JSON or XML because they are schema-driven binary, but they sacrifice human readability: you can't just open the bytes and read them.

• Speed: Protobuf serializes/deserializes fastest (numeric tags, no text parsing); JSON is slower; XML is slowest due to verbose markup.

• Size/efficiency: Protobuf omits field names on the wire and uses compact binary, so payloads are much smaller than JSON, and XML is the largest.

• Human readability: JSON and XML are text and self-describing, easy to read and debug; Protobuf is opaque binary needing the .proto schema and tooling to decode.

• Schema: Protobuf requires a predefined schema and codegen; JSON/XML can be schemaless and ad hoc, which is more flexible but less safe.

• Takeaway: Use Protobuf for internal high-performance APIs; use JSON/XML when readability, browser use, or loose coupling matter more.

gRPC is a contract-first RPC framework built on HTTP/2 and Protocol Buffers, where you call remote methods like local functions; REST is a resource-oriented style over HTTP/1.1 using verbs on URLs, usually with JSON.

• Contract and payload:

  • gRPC: a .proto file defines services and messages, generating typed client/server stubs; payloads are compact binary Protobuf.

  • REST: no enforced schema (OpenAPI is optional); payloads are typically human-readable JSON.

• Interaction model:

  • gRPC exposes method calls and supports four modes: unary, server-streaming, client-streaming, and bidirectional streaming.

  • REST maps CRUD onto HTTP verbs (GET, POST, etc.) on resources; streaming is limited.

• Transport: gRPC requires HTTP/2 (multiplexing, header compression); REST commonly runs on HTTP/1.1.

• Reach and tooling: REST is universally browser-friendly and easy to debug with curl; gRPC needs generated code and (in browsers) grpc-web.

gRPC's advantages come from performance, strong contracts, and streaming; its disadvantages come from limited browser support, reduced human-readability, and heavier tooling.

• Advantages:

  • High performance: binary Protobuf and HTTP/2 multiplexing reduce payload size and latency.

  • Strong typed contract: the .proto generates client/server code across many languages.

  • Streaming: four call types including bidirectional.

  • Built-in features: deadlines, cancellation, interceptors, and pluggable auth.

• Disadvantages:

  • Limited browser support: needs grpc-web and a proxy.

  • Not human-readable: binary payloads are harder to debug than JSON.

  • Learning curve and tooling: codegen, Protobuf, and HTTP/2 infrastructure add setup cost.

  • Ecosystem gaps: some proxies, logging, and API-management tools assume REST/JSON.

A gRPC system is contract-first: the .proto defines the service, code generation produces client stubs and server skeletons, and the gRPC runtime handles serialization and HTTP/2 transport between them.

• The .proto file: Declares service methods and message types; the single source of truth for both sides.

• Stubs (client side): Generated proxy objects: calling a stub method looks like a local call but sends an RPC.

• Skeletons / service base (server side): Generated abstract classes you implement with the real business logic.

• Server: Hosts the service implementations, listens on a port, and dispatches incoming calls.

• Client: Holds a channel/connection to the server and invokes methods through the stub.

• gRPC runtime: Handles Protobuf (de)serialization, HTTP/2 framing, streaming, deadlines, metadata, and status codes.

gRPC is an open-source, high-performance Remote Procedure Call framework from Google that lets a client call methods on a remote server as if they were local, using Protocol Buffers over HTTP/2. It was developed to make efficient, strongly-typed, polyglot communication between microservices practical at scale.

• What it is:

  • Contract-first RPC: define a service in .proto, generate client/server code in many languages.

  • Runs on HTTP/2 with Protobuf binary payloads by default.

• Why it was built:

  • Grew out of Google's internal Stubby system for massive service-to-service traffic.

  • REST/JSON was too verbose and loosely typed for high-volume internal microservices.

• Key benefits:

  • Performance (compact binary, multiplexed HTTP/2), strict contracts, and native streaming.

  • Polyglot: same contract generates consistent clients across languages.

HTTP/2 is the transport layer for gRPC: its multiplexed, binary, header-compressed streams are what make gRPC efficient and enable all four call types (unary and streaming).

• Multiplexing: Many concurrent RPCs share one TCP connection as independent streams, avoiding head-of-line blocking at the HTTP level and connection-per-call overhead.

• Binary framing: Messages travel as binary frames (not text), pairing naturally with Protobuf's compact binary payloads.

• Bidirectional streaming: Long-lived streams let client and server push messages independently, powering client-, server-, and bidi-streaming RPCs.

• Header compression (HPACK): Reduces repeated metadata overhead across many small calls.

• Metadata and flow control: gRPC maps its metadata to HTTP/2 headers/trailers, and HTTP/2 flow control keeps fast senders from overwhelming slow receivers.

gRPC is a high-performance, contract-first RPC framework whose goal is efficient, strongly-typed, cross-language service-to-service communication, built on HTTP/2 and Protocol Buffers.

• Performance: Binary Protobuf serialization plus HTTP/2 multiplexing make it far leaner than JSON-over-HTTP/1.1 for internal traffic.

• Strong contracts: A .proto file defines services and messages, giving both sides a typed, versioned interface.

• Polyglot by design: Code generation targets many languages, so services in different stacks interoperate cleanly.

• Streaming: Supports unary, server-streaming, client-streaming, and bidirectional-streaming calls natively.

• Built-in features: Deadlines/timeouts, cancellation, metadata, interceptors, pluggable auth, and load balancing.

• Best fit: Internal microservice communication; less ideal for browser-facing APIs without gRPC-Web.

gRPC's defining features are a contract-first Protobuf interface, HTTP/2 transport, four streaming modes, multi-language code generation, and a set of production-grade call features layered on top.

• Protocol Buffers: Compact, strongly-typed binary serialization and IDL for defining messages and services.

• HTTP/2 transport: Multiplexing, binary framing, and header compression on a single connection.

• Four RPC types: Unary, server streaming, client streaming, and bidirectional streaming.

• Code generation: Generates client stubs and server skeletons across many languages from one contract.

• Call features: Deadlines, cancellation, metadata (headers/trailers), interceptors, and channel-level configuration.

• Operational features: Pluggable authentication (TLS, token-based), load balancing, and health checking.

The generated stub is the client's local proxy for the remote service, and the server skeleton is the base class you implement: together they hide serialization and transport so calling a remote method looks like a normal method call.

• Client stub:

  • Exposes each RPC as a typed method; internally it marshals the request into Protobuf, sends it over HTTP/2, and unmarshals the response.

  • Comes in blocking, async/future, and streaming flavors depending on the language.

• Server skeleton/handler:

  • A generated base class (e.g. an abstract service) whose methods you override with real logic.

  • The framework decodes incoming requests, dispatches to your override, and encodes what you return.

• Shared contract: Both are generated from the same .proto, so client and server signatures stay in sync by construction.

• Value: You write business logic, not wire handling; boilerplate for encoding, transport, and errors is generated.

In gRPC you call a generated stub method with a request object and get a response object back, exactly like a local method call: the abstraction hides serialization, connection management, and the HTTP/2 round trip.

• The illusion of local calls: Your code calls stub.GetUser(request) and receives a typed reply; the wire details are invisible.

• What happens underneath:

  1. The stub serializes the request to Protobuf.

  2. It sends it over an HTTP/2 stream on a shared channel.

  3. The server deserializes, runs your handler, and returns a response the stub deserializes.

• Where the abstraction leaks: Unlike local calls, remote calls can time out or fail mid-flight, so you handle status codes, deadlines, and retries.

Code generation is the step where a compiler reads your .proto contract and produces language-specific message classes, client stubs, and server skeletons, so you never hand-write serialization or wire code.

• The toolchain: The protoc compiler plus a gRPC plugin generates code for each target language.

• What gets generated:

  1. Message types with typed accessors and serialization built in.

  2. A client stub exposing each RPC as a method.

  3. A server base class/skeleton you subclass and implement.

• Why it matters:

  • Guarantees client and server share one type-safe contract, catching mismatches at compile time.

  • Enables polyglot systems: generate the same contract into Go, Java, Python, etc.

• Workflow note: Generation is typically wired into the build so stubs regenerate whenever the .proto changes.

The service definition in a .proto file is the single source of truth for a gRPC API: it declares the service, its methods, and their request/response message types, and everything else (stubs, skeletons, validation) derives from it.

• Contract-first design: You agree on the interface before implementing either side, so client and server develop against the same spec.

• Defines method shapes: Each rpc line names a method and declares whether parameters/returns are streamed, fixing the call type.

• Drives code generation: Stubs and skeletons in every language are generated from it, keeping them consistent.

• Supports versioning/evolution: Protobuf's field numbering lets you add fields without breaking existing clients.

gRPC is the open-source evolution of Stubby, Google's internal RPC framework: Google generalized it, released it publicly in 2015, and later donated it to the CNCF to make it a vendor-neutral standard.

• Stubby (internal origin): For over a decade Google used Stubby internally to connect huge numbers of microservices, but it was tied to Google's infrastructure and never open-sourced.

• Public launch (2015): Google rebuilt the ideas on open standards, HTTP/2 for transport and Protocol Buffers for serialization, and released gRPC as an open project.

• CNCF incubation: gRPC joined the Cloud Native Computing Foundation in 2017, aligning it with Kubernetes-era cloud-native tooling and ensuring neutral governance.

• The 'g' in gRPC: Officially a recursive/rotating backronym (it changes per release), not simply 'Google', reflecting its community ownership.

Server-side streaming is an RPC where the client sends one request and the server responds with a stream of many messages over the same call, keeping the stream open until the server finishes.

• Shape: Declared as returns (stream T); one request in, N responses out, then a single closing status.

• Client behavior: The client iterates/reads messages as they arrive rather than waiting for one big response.

• Use cases:

  • Live feeds and subscriptions: price ticks, notifications, log tailing.

  • Large result sets streamed as chunks so the client processes incrementally without buffering everything.

  • Progress updates for a long-running server task.

• Benefit: Lower time-to-first-byte and bounded memory versus assembling a huge single response.

gRPC supports four RPC patterns based on whether the client and server each send one message or a stream: unary, server streaming, client streaming, and bidirectional streaming.

• Unary (1 request → 1 response): Classic request/response; use for standard CRUD-style calls and lookups.

• Server streaming (1 request → N responses): Client asks once, server pushes a stream; use for feeds, subscriptions, or chunked large results.

• Client streaming (N requests → 1 response): Client pushes a stream, server replies once at the end; use for uploads, batching, or aggregating metrics.

• Bidirectional streaming (N requests ↔ N responses): Both sides read and write independently on one call; use for chat, real-time collaboration, or interactive protocols.

• Common ground: All four run over a single HTTP/2 stream and end with one status; the stream keyword in the proto selects the pattern.

A Unary RPC is the simplest gRPC pattern: the client sends exactly one request and gets back exactly one response, just like a traditional function call or HTTP request/response.

• Shape: Declared with no stream keyword: rpc GetUser(Request) returns (Response).

• Behavior: Blocking or async, the client sends once and awaits a single response plus a closing status.

• When to use:

  • Standard operations where a request maps to one result: fetch a record, submit a form, validate a token.

  • The default choice unless data volume or interactivity clearly calls for streaming.

• Advantages: Simplest to reason about, easy to retry idempotently, and works cleanly with deadlines, load balancing, and caching.

A unary RPC is a single request that returns a single response (like a normal function call), while a streaming RPC lets one or both sides send a sequence of messages over a single long-lived call.

• Unary:

  • One request, one response; simplest and most common pattern.

  • Maps cleanly to request/response APIs.

• Streaming comes in three shapes:

  • Server streaming: one request, a stream of responses (e.g. a feed or large result set).

  • Client streaming: a stream of requests, one response (e.g. uploads, aggregation).

  • Bidirectional: independent read and write streams over one call.

• Shared transport: All are multiplexed over HTTP/2; streaming keeps the same call open, avoiding repeated connection/setup overhead.

• Defined in the .proto: The stream keyword on request and/or response type chooses the shape.

Protocol Buffers are gRPC's default Interface Definition Language and binary serialization format: you describe messages and services once in a .proto file, and the compiler generates typed, efficient serialization code and client/server stubs for many languages.

• Contract-first IDL: The .proto is the single source of truth shared by client and server across languages.

• Efficient binary wire format: Compact and fast to parse compared to JSON/XML; field numbers, not names, go on the wire.

• Code generation: protoc (with the gRPC plugin) generates message classes and stub interfaces, so you write logic not serialization.

• Schema evolution: Field numbers enable backward/forward compatibility: add new fields without breaking old clients; never reuse or renumber tags.

• Role in gRPC: It defines both the data (message) and the API surface (service with RPC methods) that gRPC transports over HTTP/2.

You declare the proto version, define message types for the data, and a service containing rpc methods that name their request and response messages; the stream keyword marks streaming methods.

• Messages:

  • Each field has a type, name, and a unique field number (its wire tag), e.g. string name = 1;.

  • Field numbers must stay stable for compatibility.

• Service and RPCs:

  • rpc Method(Request) returns (Response); defines a unary call.

  • Add stream before the request and/or response type to make it client-, server-, or bidirectional-streaming.

• Header essentials: syntax = "proto3"; plus a package and language options for generated code.

gRPC uses Protocol Buffers as its default Interface Definition Language and serialization format: you define message schemas in a .proto file, generate typed classes, and gRPC serializes messages to a compact binary form on the wire and deserializes them back into objects on the other side.

• Schema-driven: Each field has a name, type, and unique field number in the .proto; the number (not the name) is what gets encoded, keeping payloads small.

• Serialization: The generated SerializeToString() (or language equivalent) turns the object into a binary byte stream that gRPC ships in the HTTP/2 request/response body.

• Deserialization: The receiver uses the same schema to parse bytes back into a strongly typed message; unknown fields are skipped rather than failing.

• Why it fits gRPC: Binary is smaller and faster to parse than text (JSON/XML), and the shared schema gives both client and server type safety and forward/backward compatibility.

A package declaration namespaces the types in a .proto file to avoid name collisions, and import pulls in definitions from another file so you can reference its types.

• package scoping: Types are referenced as package.TypeName; the package also influences generated code namespaces (unless overridden by options like java_package or go_package).

• import: Takes a path relative to the proto include roots (the -I/proto_path), not a filesystem-relative path.

• import public: Re-exports the imported file's types so consumers of your file can use them transitively, useful when refactoring a file into pieces.

• No transitive visibility by default: A plain import only exposes that file's own types to you, not what it imports; import each file whose types you use directly.

Protobuf offers a fixed set of scalar types plus composite constructs (messages, enums, repeated fields, maps, and oneofs) that you combine to model structured data.

• Numeric scalars:

  • Variable-length: int32, int64, uint32, uint64 (varint; inefficient for negatives).

  • ZigZag: sint32, sint64 (efficient for negative numbers).

  • Fixed-width: fixed32, fixed64, sfixed32, sfixed64, float, double.

• Other scalars: bool, string (UTF-8), and bytes (arbitrary binary).

• Composite types: message (nested structures) and enum (named integer sets).

• Collections and unions: repeated for lists, map<K,V> for key/value pairs, and oneof for mutually exclusive fields.

• Defaults: In proto3 unset scalars take type zero-values (0, "", false); use wrapper well-known types when you must detect presence.

gRPC achieves cross-language support through Protocol Buffers: you define your service and messages once in a language-neutral .proto file, and the protoc compiler generates native client and server code for each target language from that single contract.

• The contract is the source of truth: The .proto defines messages and RPC signatures independently of any implementation language.

• Code generation per language: protoc plus a language plugin emits idiomatic stubs (structs/classes, serialization, client/server interfaces) in Go, Java, Python, C++, etc.

• A shared wire format: All languages serialize to the same compact protobuf binary and speak the same gRPC-over-HTTP/2 protocol, so a Go server and a Python client interoperate seamlessly.

• Consistent semantics: Status codes, deadlines, metadata, and streaming behave the same across languages, keeping behavior predictable in a polyglot system.

grpcurl is a command-line tool that acts like curl for gRPC: it lets you invoke methods, explore services, and send requests without writing client code.

• Service discovery via reflection:

  • If the server enables the reflection service, grpcurl list and grpcurl describe enumerate services, methods, and message types with no local .proto files.

  • Without reflection you point it at .proto files using -import-path and -proto.

• Invoking calls:

  • Send JSON request bodies with -d; grpcurl marshals to protobuf and prints the JSON response.

  • Pass metadata with -H and control TLS with -plaintext or -insecure.

• Why it is useful: Quick manual testing and debugging of endpoints, and verifying auth or error behavior without building a client.

Usually yes, gRPC is faster than typical JSON-over-REST, but the gain comes from its stack (binary Protobuf + HTTP/2), not magic. For text-heavy public APIs the difference can shrink, so "faster" is context dependent.

• Binary serialization: Protocol Buffers encode to compact binary that is far smaller and cheaper to parse than JSON text.

• HTTP/2 transport: Multiplexes many calls over one connection, uses header compression (HPACK), and avoids per-request connection setup.

• Streaming avoids round trips: Client, server, and bidirectional streaming push data continuously instead of polling.

• Caveat: Over a warm HTTP/2 REST connection with compression the gap narrows; gRPC's real wins show up in high-throughput, low-latency service-to-service traffic.

Choose gRPC when you control both ends and need low-latency, high-throughput, strongly-typed communication (classic internal microservices). Prefer REST/GraphQL for broad public/browser reach, and message queues when you need async, decoupled, durable delivery.

• gRPC shines for:

  • Internal microservice-to-microservice calls needing speed and a strict contract.

  • Streaming workloads (telemetry, chat, live feeds) via bidirectional streaming.

  • Polyglot systems: generate clients/servers in many languages from one .proto.

• Prefer REST when: You need public APIs, easy browser access, caching, and human-readable debugging.

• Prefer GraphQL when: Clients need flexible, client-shaped queries over many resources (aggregation for UIs).

• Prefer message queues when: Communication should be asynchronous, decoupled, and durable (event-driven, fan-out, retries). gRPC is request/response oriented, not a broker.

Most gRPC pitfalls stem from ignoring that it runs over real networks and evolves over time: breaking the schema, mishandling streams, and forgetting deadlines and message limits.

• Breaking schema compatibility: Reusing or renumbering field tags, or reusing removed fields, corrupts wire compatibility. Reserve retired numbers and only add new fields.

• No deadlines or timeouts: Without a deadline a hung server ties up client resources; always set deadlines and propagate them.

• Ignoring message size limits: Large payloads hit the default ~4MB limit; use streaming instead of giant unary messages.

• Misusing streams: Not handling backpressure, half-close, or flow control leads to memory blowups and stuck RPCs.

• Poor error handling: Overusing generic codes; use precise status codes and rich error details instead of stuffing everything into strings.

• Chatty design: Designing tiny fine-grained RPCs adds round trips; model coarser, intent-revealing methods.

gRPC trades human-friendliness and broad reach for performance and a strong contract. It excels internally but is harder to use from browsers and harder to debug than plain HTTP/JSON.

• Advantages:

  • Compact binary payloads and HTTP/2 multiplexing give lower latency and higher throughput.

  • Strongly-typed contracts and generated code across languages.

  • First-class streaming in all directions.

• Costs:

  • Not human-readable: you need tooling (grpcurl) to inspect traffic, unlike curl + JSON.

  • Limited browser support: needs grpc-web and a proxy since browsers can't speak raw HTTP/2 frames.

  • No native HTTP caching or simple proxy/load-balancer semantics like REST.

  • Steeper learning curve and build tooling (Protobuf compilation, codegen).

gRPC gets its efficiency from three layers working together: Protocol Buffers shrink the data, HTTP/2 moves it with minimal overhead, and streaming eliminates repeated round trips, which suits chatty microservice topologies.

• Protocol Buffers (the payload):

  • Schema-defined binary encoding: fields are tagged integers, so messages are small and parse fast with no field-name overhead.

  • Generated types remove ambiguity and reduce serialization cost versus text parsing.

• HTTP/2 (the transport):

  • Multiplexes many concurrent RPCs over one TCP connection, avoiding head-of-line blocking at the HTTP layer and connection churn.

  • Header compression (HPACK) and binary framing cut per-call overhead.

• Streaming (the interaction model):

  • Server, client, and bidirectional streams let services exchange sequences of messages over one call with built-in flow control.

  • Avoids polling and repeated request setup for continuous data.

gRPC fits internal, high-throughput streaming because HTTP/2 multiplexing plus persistent connections plus compact binary Protobuf keep latency and bandwidth low, and its native streaming modes let data flow continuously without repeated request setup.

• Efficient wire format: Protobuf binary is far smaller and faster to (de)serialize than JSON, which matters at large data volumes.

• HTTP/2 multiplexing: Many concurrent streams share one connection with no head-of-line blocking at the HTTP layer, and headers are compressed.

• Native streaming: Server-, client-, and bidirectional streams keep a long-lived channel open, ideal for telemetry, event feeds, or continuous updates.

• Internal context: Inside a controlled network you don't need browser reach or human-readable payloads, so gRPC's tradeoffs are almost all upside.

REST, GraphQL, and Thrift each optimize for a different priority: REST for ubiquity and simplicity, GraphQL for flexible client-driven queries, and Thrift for cross-language RPC similar to gRPC; you choose based on your consumers and traffic patterns.

• REST: Best for public APIs, browser clients, and simple CRUD where broad compatibility and easy debugging matter most.

• GraphQL: Best when clients need to shape their own responses and avoid over/under-fetching, often aggregating many backends for frontends.

• Thrift: An RPC framework (from Apache) with its own IDL and pluggable transports/protocols; consider it in existing Thrift ecosystems, though gRPC has broader momentum and HTTP/2 streaming.

• Choosing gRPC over these: Prefer gRPC for internal, low-latency, high-throughput microservice calls and streaming; prefer REST/GraphQL when the consumer is a browser or third party.

No: gRPC is displacing REST for internal service-to-service communication, but REST remains dominant for public APIs and browser-facing endpoints. They coexist, each where it fits.

• Where gRPC is winning: East-west traffic inside microservice fleets that need speed, typed contracts, and streaming.

• Where REST still leads: Public/external APIs, browser clients, and cases valuing human-readable JSON and universal tooling.

• Common real-world pattern: A public REST/GraphQL edge layer that fans out to gRPC internally, so the two complement rather than replace each other.

Yes: beyond the wire format and transport, gRPC ships an operational toolkit that REST leaves to you, including load balancing, name resolution, interceptors, deadline propagation, and pluggable auth, which shapes how it routes and manages traffic.

• Client-side load balancing and naming: A pluggable name resolver plus LB policies (e.g. round-robin) can distribute calls across backends without a separate proxy.

• Interceptors: Client/server middleware for logging, metrics, auth, and tracing applied uniformly across methods.

• Deadline and metadata propagation: Deadlines and context metadata flow through service chains, aiding distributed tracing and cancellation.

• Pluggable auth: Built-in support for TLS and per-call credentials (e.g. tokens) as first-class concepts.

• Ecosystem integration: Works cleanly with service meshes and proxies like Envoy, which natively understand gRPC for routing and retries.

gRPC's contract is the .proto file, from which code is generated: the schema is enforced by the compiler at build time, whereas OpenAPI/Swagger typically documents an already hand written REST API and is easy to drift from.

• Contract is the source of truth:

  • The .proto defines messages and services; protoc generates typed client and server code, so client and server can't disagree on shapes.

  • With OpenAPI the spec is often written or generated after the code and can drift from the real behavior.

• Compile time safety: Type mismatches surface at build time in generated stubs, not as runtime JSON parsing errors.

• Less boilerplate: Serialization, request/response classes, and client stubs are generated for every language, versus hand writing HTTP clients and DTOs.

• Built in evolution rules: Field numbers and reserved fields give clear backward/forward compatibility rules; OpenAPI has no enforced versioning discipline.

• Trade off: OpenAPI/JSON is human readable and browser friendly; gRPC's binary contract needs tooling to inspect.

gRPC is a contract-first RPC framework over HTTP/2 using binary Protocol Buffers, while REST and GraphQL are text/JSON over HTTP/1.1; gRPC is faster mainly because of compact binary serialization, HTTP/2 multiplexing, and streaming.

• REST: Resource oriented, JSON over HTTP, human readable and browser native, but verbose and no enforced schema.

• GraphQL: Single endpoint where the client shapes the query; great for flexible reads and avoiding over/under-fetching, but still JSON over HTTP/1.1.

• gRPC: Method oriented (call a function on a service), strict .proto contract, supports unary and bidirectional streaming.

• Why gRPC is fast:

  • Protobuf binary payloads are far smaller and cheaper to (de)serialize than JSON.

  • HTTP/2 multiplexes many calls over one connection and compresses headers (HPACK).

  • Persistent connections and streaming avoid repeated handshake and polling overhead.

• Trade off: Not natively callable from browsers without gRPC-Web, and binary payloads are harder to debug by eye.

Synchronous RPC is a direct, temporally coupled call where the caller waits for the callee's response; asynchronous messaging sends to a broker that decouples sender and receiver in time, letting the sender continue without waiting.

• Synchronous request/response (e.g. gRPC unary):

  • Caller blocks/awaits until it gets a result or error; both endpoints must be up at the same time.

  • Best when you need an immediate answer: reads, validations, queries that drive the next step.

• Asynchronous messaging via broker (Kafka, RabbitMQ):

  • Producer publishes and moves on; consumers process later, absorbing bursts and outages.

  • Best for fire-and-forget events, fan-out, background work, and decoupling services that scale independently.

• Trade offs:

  • RPC gives simple flow and immediate errors but couples availability and can cascade failures.

  • Messaging adds resilience and buffering but introduces eventual consistency and broker operational overhead.

• Rule of thumb: Need an answer now, use RPC; emitting a fact others react to, use messaging. Real systems mix both.

Protobuf trades human readability and self-description for speed and compactness, so its downsides mostly come from being an opaque binary format that requires the schema and tooling to work with.

• Not human readable: Binary payloads can't be inspected or debugged with plain tools like curl; you need the schema to decode.

• Schema coupling: Consumers need the .proto and a code-gen step; distributing and versioning schemas adds process overhead.

• Evolution pitfalls: Reusing or changing field numbers breaks compatibility; you must reserve removed tags and follow discipline.

• Limited native browser/JSON support: Web clients need gRPC-Web or JSON transcoding; not as plug-and-play as REST/JSON.

• Weak self-description and typing gaps: No built-in field presence for scalars in proto3 historically (defaults look like missing), and no rich types like decimals or dates without conventions.

RPC lets a program invoke a procedure in another address space (another process or machine) as if it were a local function, with the framework handling serialization and network transport. gRPC is a modern RPC framework that modernizes this with HTTP/2, Protobuf, streaming, and language neutrality.

• Core RPC idea: Client calls a stub method; the runtime marshals arguments, sends them, the server executes and returns a result: the network is abstracted away.

• How gRPC differs from older RPC (CORBA, SOAP, custom sockets):

  1. Transport: standardized on HTTP/2 rather than bespoke or heavier protocols.

  2. Payload: efficient binary Protobuf instead of verbose XML or ad-hoc formats.

  3. Streaming: first-class bidirectional streaming, not just request/response.

  4. Tooling: cross-language code generation from a single contract.

• Shared caveat: Remote calls are not truly local: latency, partial failure, and timeouts are real, which is why gRPC adds deadlines and cancellation.

The application/grpc content-type tells intermediaries and endpoints that the HTTP/2 message body carries a gRPC-framed payload (not plain JSON or REST), so it must be parsed and routed as gRPC.

• Identifies the protocol on the wire: Sent in the HTTP/2 content-type header; proxies/load balancers use it to distinguish gRPC traffic from ordinary HTTP.

• Signals the message encoding: A suffix names the codec, e.g. application/grpc+proto or application/grpc+json; bare application/grpc implies Protobuf by default.

• Enforces the length-prefixed framing: Each message is a 1-byte compression flag plus 4-byte length prefix followed by the payload; the content-type tells the receiver to expect this framing.

• Mismatch is rejected: A server receiving a wrong or missing content-type returns a protocol error, protecting against non-gRPC clients hitting a gRPC endpoint.

Contract-first means you define the service interface and messages in a .proto file first, then generate client and server code from it: the contract is the single source of truth, not the implementation.

• The proto is the authority: Services, methods, and message shapes are declared in IDL before any code exists; protoc generates typed stubs from it.

• Language independence: One contract generates consistent code for many languages, so a Go server and a Java client agree by construction.

• Early alignment: Teams agree on the API surface up front, enabling parallel work: client and server develop against the same shared definition.

• Built-in evolution rules: Field numbers and backward-compatibility rules make versioning explicit and safer than ad-hoc JSON.

• Trade-off: Requires a build/codegen step and discipline around the schema, versus schema-less REST where you can just start coding.

Streaming in gRPC lets a single RPC send a sequence of messages over one HTTP/2 stream instead of a single request/response, so client, server, or both can push data incrementally while the call stays open.

• Built on HTTP/2 multiplexing: Each RPC maps to one HTTP/2 stream; multiple length-prefixed messages flow within it, and many streams share one connection.

• Declared in the proto: The stream keyword on the request and/or response type tells codegen to produce streaming stubs.

• Programmed as streams: Generated APIs expose read/write handles: you call Send() / Recv() (or language iterators) to push and pull messages until the stream is closed.

• Ordered and flow-controlled: Messages arrive in order, and HTTP/2 flow control prevents a fast sender from overwhelming a slow receiver.

• Three streaming forms: Server-streaming, client-streaming, and bidirectional; a single terminating status closes the call.

Bidirectional streaming lets the client and server each send a stream of messages over the same call, reading and writing independently: neither side has to wait for the other to finish, so it supports fully interactive, real-time communication.

• Two independent streams on one call: Declared as rpc Chat(stream Msg) returns (stream Msg); the send and receive directions are decoupled.

• Interleaved, not lock-step: The server can push messages while still receiving from the client; each direction preserves its own ordering.

• Example: chat / collaboration: In a chat room, each client sends messages as it types while continuously receiving others' messages on the same open stream.

• Other fits: Real-time gaming state sync, live telemetry with control commands, and voice/transcription pipelines.

• Lifecycle: Either side signals it's done sending (half-close); the call completes with a single status once both sides finish.

In the Java (and similar) gRPC APIs, StreamObserver is the callback interface that both sends and receives a sequence of messages in a stream: it decouples message flow from a single return value so either side can push messages over time.

• Three core methods:

  • onNext(msg): emit (or receive) the next message in the stream.

  • onError(t): terminate the stream with an error status.

  • onCompleted(): signal the stream ended successfully.

• Used on both sides:

  • The server implements a response StreamObserver to send data, and returns a request StreamObserver for client-streaming/bidi to receive data.

  • The client passes a response observer to handle incoming messages, and gets a request observer to send them.

• Asynchronous by nature: Callbacks fire as messages arrive, so it fits streaming better than a single blocking return.

• Thread-safety note: Calls on a single StreamObserver must not be made concurrently; serialize your onNext calls.

Use streaming when data arrives incrementally or continuously, or when the payload is too large or too long-lived to fit a single request/response; use bidirectional when both sides must exchange messages independently in real time.

• Server streaming fits:

  • Large result sets you want to process as they arrive (paging, exports).

  • Live feeds: notifications, price ticks, log tailing.

• Client streaming fits:

  • Uploading large or chunked data (file upload, telemetry batches).

  • Aggregating many inputs into one summarized result.

• Bidirectional fits:

  • Real-time interactive systems: chat, gaming, collaborative editing.

  • Long-lived sessions where request and response cadence differ.

• When NOT to stream: Simple request/response with small payloads: unary is simpler, easier to load-balance and retry.

Both sides read and write messages sequentially over one HTTP/2 call: the sender emits messages until it half-closes the stream, and the receiver iterates over incoming messages until it sees end-of-stream and a final status.

• Server side:

  • For responses it writes messages (via onNext or by yielding/returning an iterator/generator) then signals completion.

  • For requests it consumes an incoming stream (iterator or a request StreamObserver).

• Client side:

  • Sends via a request iterator/observer and half-closes when done.

  • Receives responses by iterating the returned stream or through response callbacks.

• Language-shaped APIs: Java/C++ use callback-style StreamObserver; Python/Go often expose iterators/generators.

• Termination and errors: Half-close ends sending; the trailing gRPC status ends the whole call. An error status terminates the stream for both directions.

• Ordering guarantee: Messages within a single stream are delivered in order (HTTP/2 framing).

They are different stub flavors generated for the same service: a blocking stub waits for the result, an async/non-blocking stub delivers results via callbacks, and a future-based stub returns a Future you resolve later.

• Blocking (synchronous) stub:

  • The call blocks the calling thread until the response (or a full server stream) is available.

  • Simplest to use; limited to unary and server-streaming (returns an iterator).

• Async / non-blocking stub:

  • Uses callbacks (StreamObserver) so nothing blocks; the only stub that supports client-streaming and bidirectional RPCs.

  • Best for high concurrency and streaming.

• Future-based stub:

  • Returns a ListenableFuture immediately; you fetch the result or attach a listener later.

  • Unary only; a middle ground between blocking simplicity and async concurrency.

• Rule of thumb: Blocking for simple synchronous code, future for parallel unary calls, async for streaming and maximum throughput.

You compile Protocol Buffers with protoc, the protobuf compiler: it reads a .proto file and, via language-specific plugins, generates source code (message classes plus gRPC service stubs) that your application imports.

• Role of protoc: Parses and validates the schema, then delegates code generation to backends selected by output flags like --python_out or --java_out.

• Plugins:

  • The base compiler emits message types; gRPC service code needs a plugin such as grpc_python_plugin or the flag --grpc_out to generate client stubs and server base classes.

  • In Python it's common to use python -m grpc_tools.protoc, which bundles protoc and the gRPC plugin together.

• Import paths: -I / --proto_path tells the compiler where to resolve imported .proto files.

Protocol Buffers messages have no built-in exception mechanism: they only carry data, so errors are handled either by modeling them explicitly as fields in the message or, in gRPC, by using the transport-level status codes and error details rather than the message body.

• gRPC status codes are the primary channel: Return a code like NOT_FOUND or INVALID_ARGUMENT with a message; this is separate from the protobuf payload.

• Rich error details: The google.rpc.Status message can attach structured error payloads (e.g. ErrorInfo, BadRequest) for machine-readable details.

• Modeling errors in the message itself: A response can use a oneof of a success result or an error message when errors are part of normal domain flow.

• Parsing failures: Malformed bytes raise a decode error in the generated library (e.g. DecodeError); missing optional fields are not errors, they just take defaults.

proto3 is a simplified evolution of proto2: it drops required fields and explicit defaults, changes how presence works, and streamlines syntax to improve cross-language consistency and compatibility. Both share the same wire format but differ in language semantics.

• Field rules: proto2 has required, optional, and repeated; proto3 removed required (it caused evolution problems) and made fields implicitly optional.

• Default values: proto2 lets you set custom defaults; proto3 only allows type-based defaults (0, empty string, false).

• Presence: proto2 always tracks whether a scalar was set; proto3 originally could not distinguish unset from default until the optional keyword was reintroduced.

• Enums: proto3 requires the first enum value to be 0 (the default); proto2 is more permissive.

• Other: proto3 tightened syntax and improved support for JSON mapping and newer languages; it's the recommended default for gRPC.

In proto3 every scalar field has a type-based default (0, empty string/bytes, false, first enum value), and by default an unset field is indistinguishable from one explicitly set to its default. The optional keyword re-adds explicit field presence so you can tell "unset" apart from "set to default".

• Default values: Reading an unset scalar returns its zero value; defaults are not sent on the wire, saving space.

• The presence problem: Without optional, a field equal to 0 could mean "the user chose 0" or "nothing was sent": ambiguous.

• What optional does:

  • It gives the field explicit presence tracking, generating a has_field() accessor so you can check whether it was actually set.

  • Internally it's implemented like a single-field oneof.

• Always-present cases: Message-typed fields already have presence (they can be null/unset); repeated fields do not, an empty list is just empty.

A oneof is a group of fields where at most one can be set at a time: they share memory, so setting one clears the others. Use it to model mutually exclusive alternatives (a union type).

• Mutual exclusivity: All member fields share the same storage; only the last one set is retained, and the generated code exposes a case/which accessor.

• Wire representation: Each member keeps its own field number and is encoded normally; the runtime just enforces that only one is present.

• When to use it: Alternative payloads (e.g., a response that is either a result or an error), or a message that carries one of several event kinds.

• Limitations: Cannot contain repeated fields or maps, and members can't be required. Adding/removing members is fine, but moving a field in or out of a oneof breaks wire semantics.

A map<K, V> is an associative field with typed keys and values. It is pure syntactic sugar: on the wire it is encoded exactly as a repeated message of key/value entries.

• Key and value types: Keys must be integral or string types (not float, bytes, or messages); values can be any type except another map.

• Wire equivalence: map<string, int32> m = 1; is identical on the wire to a repeated Entry m = 1; where Entry has key = 1 and value = 2.

• No ordering guarantee: Entry order on the wire is unspecified, so maps are a common source of non-deterministic serialization.

• Duplicate keys: If a parser sees the same key twice, the last one wins; missing values decode to the type's default.

• Practical implication: Because it's just repeated entries, you can even switch between a map and the equivalent repeated message without breaking wire compatibility.

An enum defines a set of named integer constants. In proto3 the first value must be zero and acts as the default; enums are stored as varints on the wire and have specific rules around unknown values.

• Zero default: The first entry must be 0 (conventionally UNSPECIFIED) and is the value when the field is unset.

• Unknown values are preserved: In proto3, an unrecognized enum number is kept as-is (open enums), so a newer sender's value survives a round-trip through an older reader that doesn't know the name.

• Compatibility rules:

  • Adding new values is safe; never change or reuse an existing number for a different meaning.

  • Renaming a value keeps wire compatibility (numbers matter, not names) but is a source-level break.

• Aliases: Two names can map to the same number only if you set option allow_alias = true;.

Well-known types are standard messages shipped by Google in google/protobuf/*.proto that cover common needs so teams don't reinvent them, with idiomatic language mappings and canonical JSON representations.

• Timestamp: A point in time as seconds and nanos since the Unix epoch (UTC); use for absolute times like created-at.

• Duration: A signed span of time (seconds + nanos); use for timeouts, retention, elapsed intervals.

• Any: Wraps an arbitrary serialized message plus a type URL; use when the concrete type isn't known until runtime (prefer oneof when the set is fixed).

• Empty: A message with no fields; use as an RPC request or response that carries no data.

• Wrappers (Int32Value, StringValue, etc.): Box scalars in a message so you can distinguish "unset" from the zero default, which proto3 scalars can't express.

• Also useful: FieldMask for partial update semantics, and Struct/Value for arbitrary JSON-like data.

In gRPC, context (e.g. context.Context in Go) carries per-call metadata, deadlines, and cancellation signals; you pass it down the call chain so that timeouts and cancellations propagate automatically.

• What context holds: Deadline/timeout, cancellation state, and request-scoped values like metadata (headers).

• How it flows:

  • The client creates a context and passes it to the stub call; on the server the handler receives a context derived from the incoming RPC.

  • Pass the same context into downstream calls so a cancelled or expired parent aborts children.

• Deriving new contexts: Use context.WithTimeout, context.WithCancel, or context.WithValue to add behavior without mutating the parent.

• Best practice: Context is the first argument, never stored in a struct, and used for cross-cutting concerns not for passing optional business parameters.

Deadlines and timeouts both bound how long an RPC may run, preventing calls from hanging forever; the difference is that a timeout is a duration ("5s from now") while a deadline is an absolute point in time.

• Timeout: relative: "Fail if not done within N seconds", convenient at the call site.

• Deadline: absolute: A fixed timestamp all hops share, so propagating it across services stays correct regardless of network delay.

• Why deadlines win for distributed calls: gRPC transmits the deadline on the wire; each service subtracts elapsed time, so the whole chain honors one budget instead of each hop resetting a fresh timeout.

• Relationship: A timeout is just a convenient way to compute a deadline (now + timeout); gRPC works internally with deadlines.

The client sets a deadline and gRPC sends it to the server on the wire; if it expires, the client stops waiting and the server observes the cancellation via its context, letting both sides abandon the work.

• Client side:

  • Attaches a deadline to the call context; when it passes, the RPC returns immediately with status DEADLINE_EXCEEDED.

  • gRPC does not automatically retry, it just fails.

• Server side:

  • Receives the remaining time budget; the handler context is cancelled when the deadline expires.

  • A well-behaved server checks ctx.Done() / ctx.Err() and stops work (DB queries, downstream calls) rather than finishing a response nobody will read.

• Propagation: Passing the same context into downstream RPCs forwards the shrinking deadline through the whole call graph.

A deadline is the absolute time by which an RPC must complete or be aborted; it is essential because without it a slow or dead dependency can tie up threads, connections, and memory across the whole system.

• Bounds resource usage: Prevents calls from hanging indefinitely, freeing goroutines/threads and connections for other work.

• Prevents cascading failure: Without deadlines, one slow service backs up its callers, then their callers, exhausting resources system-wide.

• Shared budget across hops: Because the deadline is absolute and propagated, an A→B→C chain shares one time budget instead of multiplying timeouts.

• Default matters: gRPC has no deadline by default, so calls can wait forever: always set one explicitly.

Metadata is key-value information sent alongside an RPC (like HTTP headers), used for cross-cutting concerns such as auth tokens, tracing IDs, and request context without polluting the message schema.

• Two kinds:

  • Headers: sent before the response, e.g. an authorization bearer token.

  • Trailers: sent after the response, e.g. status details or metrics.

• Common uses: Authentication (tokens), tracing/correlation IDs, tenant/locale info, and API versioning.

• Rules:

  • Keys are lowercase ASCII; keys ending in -bin carry binary values (base64 on the wire).

  • Reserved grpc- prefixed keys are used internally (e.g. deadline).

• Access: Clients attach it to the outgoing context; servers read it from the incoming context, often via interceptors.

Authentication in gRPC is normally handled with TLS for channel security plus per-call credentials (tokens) in metadata, while authorization is enforced in interceptors that inspect the caller's identity before the handler runs.

• Transport security: Use TLS to encrypt and, with mTLS, mutually authenticate client and server via certificates.

• Call credentials (authentication):

  • Attach a token (JWT, OAuth2) in the authorization metadata header; the server validates it.

  • gRPC supports per-call credential objects that inject tokens automatically on every call.

• Authorization:

  • After identity is verified, check roles/scopes/permissions for the requested method.

  • Centralize this in a server interceptor so every RPC is checked consistently, not scattered in handlers.

• Best practices:

  • Always pair token credentials with TLS (tokens in plaintext are stealable).

  • Propagate identity downstream through metadata for service-to-service auth.

gRPC security operates at two layers: transport security (encrypting the channel with TLS or mTLS) and authentication of the caller (proving identity via certificates or tokens carried in metadata).

• Transport security with TLS:

  • Encrypts data in transit and authenticates the server to the client; set via channel credentials.

  • Prevents eavesdropping and man-in-the-middle attacks.

• Mutual TLS (mTLS):

  • Both client and server present certificates, so each verifies the other's identity.

  • Common for service-to-service auth inside a mesh (zero-trust networking).

• Token-based authentication:

  • Carry credentials (OAuth2/JWT, API keys) in request metadata (e.g. the authorization header) via call credentials.

  • Always combine with TLS: tokens over an unencrypted channel are trivially stolen.

• Defense in depth:

  • Use interceptors to centralize authentication/authorization checks.

  • Add rate limiting, input validation, and least-privilege authorization on top of transport security.

gRPC layers TLS on its HTTP/2 transport through channel credentials: the client uses a CA root to verify the server's certificate, establishing an encrypted, authenticated channel. Mutual TLS extends this so the server also verifies a client certificate.

• Server-side TLS:

  • Server loads its certificate and private key; client is configured with the CA that signed it.

  • The TLS handshake authenticates the server and negotiates session keys.

• Mutual TLS:

  • Server is configured to require and verify a client certificate against a trusted CA.

  • Provides strong, cryptographic identity for both peers without needing tokens.

• Configuration in code: Clients use secure channel credentials; servers install server credentials with the cert/key pair.

gRPC represents the outcome of every RPC as a status: a numeric code from a fixed set of canonical codes, plus an optional human-readable message and optional details. OK means success; any other code signals failure and is delivered as trailers.

• Status structure:

  • A code (enum), a message string, and optional structured details.

  • Servers return it explicitly; the client receives it as a StatusRuntimeException / RpcError.

• Canonical codes (common ones):

  • INVALID_ARGUMENT, NOT_FOUND, ALREADY_EXISTS: client-side/data problems.

  • UNAUTHENTICATED, PERMISSION_DENIED: identity/authorization.

  • DEADLINE_EXCEEDED, UNAVAILABLE, RESOURCE_EXHAUSTED: transient/infra issues, often retryable.

  • INTERNAL, UNKNOWN, UNIMPLEMENTED: server-side failures.

• Why canonical codes matter:

  • They give a language-agnostic, standardized vocabulary shared across all gRPC languages.

  • Enable generic behavior like deciding retryability without parsing messages.

gRPC has built-in, transparent retries configured declaratively via a service config (usually delivered by the name resolver or set on the channel). You specify which status codes are retryable, how many attempts, and an exponential backoff policy: gRPC then retries eligible failed calls automatically.

• Retry policy fields:

  • maxAttempts: total tries including the original.

  • initialBackoff, maxBackoff, backoffMultiplier: exponential backoff timing.

  • retryableStatusCodes: which codes trigger a retry (e.g. UNAVAILABLE).

• How to enable it:

  • Provide a JSON service config on the channel (option grpc.service_config) or via the resolver.

  • Retries must be enabled on the channel (on by default in modern versions).

• Safety considerations:

  • Only retry idempotent operations, or you may duplicate side effects.

  • gRPC also supports throttling to avoid retry storms; combine with deadlines.

Basic error handling means the server aborts an RPC with a status code and message; rich error handling attaches structured, typed details using the google.rpc.Status model, so clients can programmatically react to specifics (which field was invalid, retry timing, etc.).

• Basic errors:

  • Server sets a canonical code plus message (e.g. context.abort(NOT_FOUND, "user missing")).

  • Client catches the error and inspects .code() and .details().

• Rich error details:

  • Encode a google.rpc.Status whose details hold typed messages like BadRequest, RetryInfo, ErrorInfo, QuotaFailure.

  • Serialized into the grpc-status-details-bin trailer; client decodes them back into typed objects.

• Good practices:

  • Pick the most precise canonical code; keep messages safe (no sensitive data).

  • Use interceptors to translate exceptions into consistent statuses centrally.

Server reflection is a gRPC service that lets a client discover, at runtime, which services and methods a server exposes and what their message schemas are, without having the .proto files on hand. It's essentially the server describing its own API.

• How it works:

  • The server registers grpc.reflection.v1.ServerReflection, which answers queries for service names and their descriptors.

  • It returns the FileDescriptorProto data so a client can reconstruct the schema dynamically.

• Why it's useful:

  • CLI and GUI tools like grpcurl and Postman can call services with no local .proto, great for debugging and exploration.

  • Enables generic proxies, dashboards, and testing tools to work against any server.

• Caveat: It exposes your API surface, so many teams disable reflection in production or restrict it for security.

gRPC-Gateway is a plugin that generates a reverse-proxy server which exposes your gRPC service as a RESTful JSON/HTTP API. It lets HTTP clients that can't (or won't) speak gRPC still reach the same backend, translating JSON requests into protobuf calls and back.

• How mappings are defined:

  • You annotate RPC methods with google.api.http options that map an HTTP verb and path to the method (e.g. GET /v1/users/{id}).

  • The generated gateway parses path/query/body into the request message and marshals the reply to JSON.

• Deployment shapes: Run the gateway as a separate proxy in front of the gRPC server, or use in-process transcoding (some proxies like Envoy do JSON transcoding natively).

• Why it's valuable:

  • One .proto serves both gRPC and REST clients, avoiding a second hand-written API.

  • Useful for browsers, third parties, and tools that expect plain REST/JSON.

gRPC-Web is a variant of the gRPC protocol designed for browsers. Browsers can't use standard gRPC because they don't give JavaScript the low-level control over HTTP/2 frames that gRPC needs, so gRPC-Web uses a browser-compatible encoding and relies on a proxy to translate between it and real gRPC.

• Why browsers can't do native gRPC:

  • The Fetch/XHR APIs don't expose HTTP/2 framing, trailers, or full-duplex stream control that gRPC depends on.

  • gRPC relies on HTTP/2 trailers (for grpc-status) that browser JS cannot read directly.

• What gRPC-Web changes:

  • Defines a wire format that packs trailers into the response body so it works over normal HTTP/1.1 or HTTP/2 requests.

  • Supports unary and server-streaming, but not client or bidirectional streaming.

• Why a proxy is required: A proxy (Envoy's gRPC-Web filter or the standalone gRPC-Web proxy) translates gRPC-Web requests into standard gRPC for the backend and converts responses back.

The gRPC health checking protocol is a standard service (grpc.health.v1.Health) that lets clients and infrastructure ask a server whether it (or a specific service) is able to serve traffic. It gives orchestration and load balancing a uniform, gRPC-native way to probe liveness and readiness.

• The interface:

  • Check: a unary RPC that returns a status of SERVING, NOT_SERVING, or UNKNOWN.

  • Watch: a server-streaming RPC that pushes status changes so watchers react immediately.

  • A request names a service (empty string means the whole server).

• How infrastructure uses it:

  • Kubernetes can run a gRPC liveness/readiness probe against the Health service to decide restarts and traffic routing.

  • Load balancers and service meshes drop NOT_SERVING backends from rotation.

• Why it's better than a TCP check: A TCP connect only proves the port is open; the health check confirms the application logic is actually ready to serve.

A gRPC Channel is the client-side abstraction of a virtual connection to a server (target), managing the underlying HTTP/2 connections, name resolution, and load balancing so that stubs can issue RPCs without dealing with transport details.

• What it represents: A logical pipe to a target (host:port or a resolvable name), not a single socket: it may hold multiple subchannels/connections behind the scenes.

• What it handles for you:

  • Name resolution (DNS or custom resolvers) into backend addresses.

  • Load balancing across resolved addresses.

  • Connection management: establishing, multiplexing RPCs over HTTP/2, reconnecting, and tracking connectivity state.

• Relationship to stubs: You create one channel and construct one or more stubs/clients on top of it; the stub turns method calls into RPCs sent through the channel.

• Lifecycle: It is expensive to create and meant to be long-lived and shared; close it explicitly (shutdown()/close()) to release resources.

Channels are heavyweight and designed to be long-lived: reusing one amortizes connection setup and lets gRPC multiplex many RPCs over a single HTTP/2 connection, whereas creating one per request wastes resources and adds latency.

• Setup cost is real: Each new channel triggers name resolution, TCP connection, and TLS handshake: expensive per-request overhead.

• HTTP/2 multiplexing: A single connection carries many concurrent streams, so one shared channel serves high call volume without per-call sockets.

• Load balancing and health: A persistent channel keeps resolver/LB state and connectivity tracking warm, spreading load and reconnecting seamlessly.

• Cost of per-request channels: Connection churn, port exhaustion, added tail latency, and losing the benefits above.

• Practical guidance: Create the channel once (often app startup), share it across threads (channels are thread-safe), and close it on shutdown.

Interceptors are middleware for gRPC: they wrap RPC invocation on the client or handling on the server, letting you run cross-cutting logic (auth, logging, metrics) around a call without touching business code.

• How they work:

  • Each interceptor receives the call context and a handle to the next step; it can inspect/modify metadata and requests, then invoke the continuation and post-process the response or error.

  • They chain: multiple interceptors form a pipeline executed in order around the actual method.

• Client vs server:

  • Client interceptors wrap outbound calls (attach auth tokens, add deadlines, retry/log).

  • Server interceptors wrap inbound handlers (authenticate, authorize, record metrics).

• Unary vs streaming: Unary interceptors handle single request/response; streaming interceptors wrap the stream so you can intercept individual messages.

• Common use cases: Authentication/authorization, logging and tracing, metrics, error mapping, request validation, and injecting deadlines or retries.

Interceptors are gRPC's middleware: they wrap every RPC to handle cross-cutting concerns uniformly, so the same logic doesn't get copied into each handler.

• Observability: Logging, metrics (latency, error rates), and distributed tracing span creation.

• Security: Authentication and authorization: validate tokens from metadata, reject with UNAUTHENTICATED / PERMISSION_DENIED.

• Reliability: Retries, hedging, timeouts/deadline enforcement, circuit breaking, rate limiting.

• Traffic management: Priority/concurrency control, request coalescing, load-shedding.

• Data handling: Validation, compression, response shaping, and error normalization.

• Context propagation: Passing correlation IDs, tenant/locale, and trace headers through metadata.

Both sides use interceptors to wrap an RPC and call the next handler in the chain, but the client interceptor wraps the outbound call (before it leaves) while the server interceptor wraps inbound handling (before the handler runs), and each comes in unary and streaming variants.

• Client-side interceptor:

  • Runs on the caller: can add metadata, set deadlines, retry, hedge, or record call metrics.

  • Receives the method, request, and an invoker; calls the invoker to actually send the RPC.

• Server-side interceptor:

  • Runs on the receiver: can authenticate, validate, log, enforce limits, or extract trace context.

  • Receives the request and a handler; calls the handler to invoke the actual method.

• Unary vs streaming: Unary interceptors see one request/response; streaming interceptors wrap the stream object to observe each message.

• Registration: Client: attached when building the channel/stub. Server: registered when constructing the server.

gRPC ships several built-in load balancing policies, chosen via the service config; the two most common are pick_first (the default, one connection) and round_robin (spread RPCs across all backends).

• pick_first:

  • Tries resolved addresses in order and sticks with the first that connects, using a single connection for all RPCs.

  • Lowest overhead; good default when a proxy or L4 balancer sits behind it.

• round_robin:

  • Opens a subchannel to every backend and rotates RPCs evenly across the ready ones.

  • Best for client-side balancing across a known set of pods/instances.

• weighted_round_robin: Distributes based on backend-reported load/weight to account for uneven capacity.

• ring_hash / consistent hashing: Routes by a hash of a request key for session affinity and cache locality.

• grpclb (legacy): An external balancer told clients which backends to use; now largely superseded by xDS.

• How to select one: Set it in the loadBalancingConfig of the service config, or pass it via channel options.

gRPC can compress message payloads per-call using a registered compressor; the sender sets an encoding, advertises what it supports, and the receiver decompresses transparently. It's negotiated via HTTP/2 headers, and compression applies to message bodies, not the whole stream.

• Supported codecs: gzip is the common built-in; deflate and identity (no compression) are also defined, and custom compressors can be registered.

• Negotiation:

  • The message carries grpc-encoding, and the client sends grpc-accept-encoding to advertise what it can decode.

  • If a peer can't decompress the chosen codec, the call fails with UNIMPLEMENTED.

• Per-message granularity: Each message has a compressed-flag byte, so within a stream some messages may be compressed and others not.

• Configuration: Enable via call options / channel settings (e.g. grpc.UseCompressor("gzip") in Go or a client interceptor in Java).

• Tradeoffs: Saves bandwidth for large/repetitive payloads but adds CPU cost; small messages may not be worth compressing.

Test gRPC at multiple layers: unit-test service logic in isolation, use in-process or real servers for integration, and lean on generated stubs plus tooling like grpcurl for exploratory testing.

• Unit tests:

  • Call the service handler directly with a fake request and a mock/stub context; assert on the returned message or thrown status.

  • Mock downstream dependencies so you test business logic, not transport.

• Integration tests with a real channel:

  • Spin up the server on an in-process transport or an ephemeral port, connect a real client stub, and exercise the wire path (serialization, interceptors, status codes).

  • Test all four call types: unary, server-streaming, client-streaming, and bidirectional.

• Error and edge cases: Assert correct status codes (e.g. INVALID_ARGUMENT, NOT_FOUND), deadline/cancellation behavior, and metadata handling.

• Tooling:

  • grpcurl or Postman for manual/exploratory calls; requires server reflection or the .proto.

  • Contract testing against the .proto to catch breaking schema changes across teams.

gRPC enforces a default inbound message limit (commonly 4 MB); for large payloads you either raise the limit, or better, stream the data in chunks so no single message is huge.

• Default limits exist to prevent memory exhaustion:

  • Receiving a message over the max raises RESOURCE_EXHAUSTED.

  • Adjust via options like maxReceiveMessageSize / maxSendMessageSize (names vary by language).

• Prefer streaming over one giant message:

  • Split large files/datasets into a stream of chunks (e.g. a stream bytes of fixed-size blocks).

  • Keeps memory bounded and lets the receiver process incrementally.

• Enable compression: gzip/deflate reduces wire size for compressible payloads, though it costs CPU.

• Consider not sending huge blobs at all: For very large objects, pass a reference (URL to blob storage) instead of embedding bytes in the message.

Field numbers (tags) are the true identity of each field on the wire: Protobuf serializes by tag number, not by field name, so keeping tag numbers stable is what makes schema evolution safe and backward/forward compatible.

• The tag is the wire identifier:

  • Each encoded field is a key of (field number << 3 | wire type), so decoders match data by number, ignoring the name.

  • You can freely rename a field without breaking anything, as long as the number stays.

• Stable numbers enable evolution:

  • Old code reading new data skips unknown tags; new code reading old data sees missing fields as defaults.

  • Adding a field just means picking a new, unused number.

• Numbers also affect encoding size: Tags 1 to 15 use one byte, so assign them to the most frequently used fields.

• The cardinal rule: Never change a field's number after release, and never reuse an old number for a different field.

reserved declarations block a set of field numbers (or names) from ever being used again in a message, protecting you from silent data corruption after a field is deleted.

• What they are:

  • reserved 2, 15, 9 to 11; marks numbers off-limits; reserved "foo", "bar"; marks names off-limits.

  • The compiler then errors if anyone tries to reuse them.

• Why reusing a tag is dangerous:

  • Old clients/data still associate that number with the old field's meaning and type.

  • A new field on the same number will decode old bytes as the wrong field: silent, hard-to-debug data corruption rather than a clean error.

• Reserve both number and name: The number protects wire compatibility; the name protects source/JSON compatibility and prevents confusing reuse in code.

Metadata is key-value context attached to an RPC: headers are sent before the message body (leading), trailers are sent after it (trailing), and binary metadata is any value whose key ends in -bin, allowing non-ASCII bytes.

• Headers (leading metadata):

  • Sent first, before any response message, so they must be known up front (auth tokens, request IDs, custom routing info).

  • On the client they are available as soon as the response stream begins.

• Trailers (trailing metadata):

  • Sent after the message body, so they can carry values computed during processing (final status, grpc-status, grpc-message, metrics).

  • Essential for streaming: the status can only be known once all messages have been produced.

• Binary metadata:

  • Keys ending in -bin hold arbitrary bytes; gRPC base64-encodes them on the wire and decodes automatically.

  • Non-binary values must be ASCII strings; use -bin for serialized protobufs or raw byte payloads.

You make gRPC highly available by combining client-side resilience (retries, deadlines, load balancing) with infrastructure redundancy (multiple replicas, health checks) so a single failure never takes down the call path.

• Redundancy and load balancing: Run multiple server instances; use client-side or proxy load balancing that understands HTTP/2 long-lived connections (per-request, not per-connection).

• Deadlines and timeouts: Every RPC carries a deadline so failures fail fast instead of hanging.

• Retries with backoff: Retry only idempotent methods, using exponential backoff and retry budgets to avoid retry storms.

• Health checking: Expose the standard grpc.health.v1.Health service so load balancers route only to healthy instances.

• Circuit breaking and failover: Trip breakers on unhealthy backends; deploy across zones/regions for failover.

• Observability: Metrics, tracing, and logging (often via a service mesh) to detect and isolate failures quickly.

You would gain most of the raw performance benefits (binary serialization plus HTTP/2 multiplexing), but you would still be rebuilding by hand what gRPC gives you as an integrated framework: the code generation, streaming semantics, and a defined service contract. So it can approximate gRPC, but gRPC still adds real value.

• What you'd actually get: Smaller payloads from Protobuf and connection efficiency from HTTP/2: the two biggest performance wins.

• What you'd still be missing:

  • Generated, type-safe stubs from a .proto so client and server stay in sync automatically.

  • First-class streaming abstractions (client, server, bidirectional) instead of DIY chunking.

  • Built-in features: deadlines, cancellation, interceptors, status codes, load-balancing, and health checks.

• Bottom line: Protobuf + HTTP/2 is essentially reinventing gRPC's foundation; unless you have a reason to avoid the framework, adopting gRPC saves that effort.

gRPC improves reliability through explicit status codes, per-call deadlines and cancellation, retries with backoff, and health checking, all layered on HTTP/2's connection management so failures are surfaced and handled predictably.

• Status codes: Every call returns a structured code (OK, DEADLINE_EXCEEDED, UNAVAILABLE, etc.) so clients react programmatically.

• Deadlines and cancellation: A deadline propagates through the call chain, freeing resources and preventing hung requests; clients can cancel in-flight calls.

• Retries and hedging: Built-in retry policies with backoff on retriable codes, configurable via service config.

• Load balancing and health checks: Client-side LB plus the standard health-checking protocol route traffic away from unhealthy backends.

• Connection resilience: Keepalives and automatic reconnection detect and recover from broken HTTP/2 connections.

Migrate incrementally: define .proto contracts from your existing REST models, run gRPC alongside REST, and move clients over service by service rather than doing a big bang rewrite.

1. Model the contracts: Translate REST resources and payloads into service and message definitions, choosing unary vs streaming per endpoint.

2. Run both stacks together: Keep REST live and expose gRPC in parallel; share the same business logic behind both entry points.

3. Bridge for external/browser clients: Use grpc-gateway or gRPC-Web so HTTP/JSON callers still work while backends move to native gRPC.

4. Migrate internal service-to-service calls first: East-west traffic benefits most (performance, typing) and is fully under your control.

5. Verify and cut over: Compare responses, monitor latency/errors, then deprecate REST endpoints once traffic has shifted.

6. Mind the infrastructure: Ensure HTTP/2 support end to end and load balancers that handle long-lived HTTP/2 connections.

All three are efficient binary, schema-based serialization formats; the differences are in how the schema is used at read time and what ecosystem they target. Protobuf and Thrift embed field tags and are RPC-oriented, while Avro relies on the schema being available at decode time and shines for big-data storage.

• Protocol Buffers:

  • Tagged fields (numbers) make schema evolution simple; you can decode without the writer's schema.

  • Serialization only; pairs with gRPC for transport. Broad language support.

• Apache Thrift: Like Protobuf, tagged fields, but ships a full RPC stack (serialization + transport + server) in one framework.

• Apache Avro:

  • No per-field tags in the payload; the reader needs the writer's schema (often via a schema registry).

  • Very compact, dynamic-schema friendly, dominant in the Hadoop/Kafka data ecosystem.

• Choosing: RPC/microservices: Protobuf (with gRPC) or Thrift. Data pipelines/storage with evolving schemas: Avro.

gRPC inherits HTTP/2 flow control: each stream has a receive window, and a slow receiver stops advertising window space so the sender is throttled (backpressure) instead of overwhelming it. This prevents unbounded memory growth when producer and consumer run at different speeds.

• HTTP/2 windows: Per-stream and per-connection windows limit unacknowledged bytes in flight; the sender pauses when the window is exhausted.

• Backpressure surfaces in the API:

  • In callback APIs, isReady() / onReady tell you when it is safe to write more; ignoring them buffers unbounded in memory.

  • In iterator/blocking APIs, the write simply blocks until space frees up.

• Why it matters: A fast producer with a slow consumer would otherwise cause OOM or huge latency; flow control keeps memory bounded and matches rates.

• Practical guidance: Respect isReady() before onNext in high-volume streams; consider window sizing and message batching for throughput.

Protobuf's wire format encodes each field as a key followed by its value, where the key packs the field number and a wire type; most fields are tag-value, and length-delimited types (strings, bytes, embedded messages) are tag-length-value. It's compact because it drops field names, uses variable-length integers, and skips absent fields entirely.

• The tag (key): A single varint holding (field_number << 3) | wire_type; the low 3 bits are the wire type.

• Wire types decide the value layout:

  • 0 = varint (ints, bools, enums), 1 = 64-bit fixed, 5 = 32-bit fixed.

  • 2 = length-delimited: a varint length precedes the bytes, giving the full tag-length-value shape for strings and nested messages.

• Why it beats JSON:

  • No field name strings, braces, or quotes: just a small numeric tag per field.

  • Numbers are binary varints, not ASCII digits.

  • Fields at their default value can be omitted entirely, so sparse messages are tiny.

A varint is a variable-length encoding of an integer using 1 to 10 bytes, where 7 bits per byte hold data and the top bit signals whether more bytes follow, so small numbers take few bytes. Zigzag encoding is applied to signed types (sint32/sint64) so that small-magnitude negatives don't blow up to 10 bytes.

• How varints work:

  • Each byte uses its low 7 bits for value and the high bit (MSB) as a continuation flag; values are stored little-endian in groups of 7 bits.

  • So 1 fits in one byte while large numbers grow as needed.

• The negative-number problem: With plain int32, a negative value is sign-extended to 64 bits, so -1 always encodes as 10 bytes.

• Zigzag fix:

  • It maps signed to unsigned so magnitudes near zero stay small: 0→0, -1→1, 1→2, -2→3, etc.

  • Formula: (n << 1) ^ (n >> 31) for 32-bit, keeping small negatives to 1 byte.

• Rule of thumb: Use sint32/sint64 when values are frequently negative; int32 is fine for mostly-positive numbers.

Packed repeated fields encode a repeated scalar field as a single length-delimited block of contiguous values instead of repeating the tag before every element, cutting overhead. In proto3 this is the default for repeated scalar numeric fields.

• Unpacked (old behavior): Each element gets its own tag byte, so a list of N numbers pays N tags.

• Packed: One tag plus one length, then all values back-to-back: the per-element tag overhead disappears.

• Scope:

  • Only applies to repeated scalar numeric types (ints, floats, bools, enums), not strings or messages, which are already length-delimited.

  • In proto2 you enable it with [packed=true]; in proto3 it is on by default.

• Compatibility: Parsers accept both packed and unpacked for these fields, so switching is wire-compatible.