gRPC interview questions

What a strong answer covers

• Define gRPC as a modern, high-performance Remote Procedure Call (RPC) framework developed by Google.
• Mention its core components: Protocol Buffers for Interface Definition Language (IDL) and serialization, and HTTP/2 for the transport protocol.
• List primary advantages: binary serialization (smaller messages, faster parsing), HTTP/2 multiplexing (single connection for multiple requests), built-in streaming capabilities, strong type-checking via generated code, and language neutrality.
• Contrast with REST's typical JSON/HTTP/1.1, resource-oriented approach, highlighting gRPC's efficiency for inter-service communication.

Where people lose the point

• ×Failing to mention Protocol Buffers or HTTP/2 as fundamental components of gRPC.
• ×Overstating gRPC's suitability for all use cases, especially public APIs or browser compatibility where REST often excels.
• ×Not clearly articulating *why* gRPC offers performance benefits (e.g., binary vs. text, multiplexing).

What a strong answer covers

• Define Protocol Buffers (Protobuf) as gRPC's Interface Definition Language (IDL) and its primary serialization format.
• Explain how `.proto` files are used to define structured messages and service methods, acting as a contract between client and server.
• Discuss binary serialization: Protobuf serializes data into a compact binary format, leading to smaller message sizes and faster serialization/deserialization compared to text-based formats like JSON.
• Describe code generation: The `protoc` compiler generates strongly typed client and server code in various languages from `.proto` files, ensuring type safety and reducing boilerplate.

Where people lose the point

• ×Confusing Protobuf with JSON or XML, or not understanding its binary nature.
• ×Not mentioning the `protoc` compiler or the concept of code generation for different languages.
• ×Missing the importance of field numbers for backward and forward compatibility.

What a strong answer covers

• **Unary RPC**: Client sends a single request, server responds with a single response (e.g., `GetUser(UserID) -> UserProfile`). Use case: typical request-response operations like fetching a user profile or creating an order.
• **Server-side Streaming RPC**: Client sends a single request, server responds with a stream of messages (e.g., `SubscribeToStockUpdates(Ticker) -> Stream<StockPrice>`). Use case: real-time data feeds, large data downloads, or continuous updates.
• **Client-side Streaming RPC**: Client sends a stream of messages, server responds with a single response (e.g., `UploadLogs(Stream<LogEntry>) -> UploadSummary`). Use case: uploading large files in chunks, sending a batch of log entries, or aggregating data from the client.
• **Bidirectional Streaming RPC**: Both client and server send independent streams of messages to each other (e.g., `ChatSession(Stream<ChatMessage>) <-> Stream<ChatMessage>`). Use case: real-time interactive applications like chat, video conferencing, or live data synchronization.

Where people lose the point

• ×Incorrectly describing the flow of messages (who sends what, when) for any of the streaming types.
• ×Providing generic or unrealistic use cases that don't clearly illustrate the pattern's benefit.
• ×Not clearly distinguishing between the client and server roles in initiating and terminating streams.

What a strong answer covers

• Explain that HTTP/2 is the underlying transport protocol for gRPC, providing the foundation for its communication model.
• Discuss **Multiplexing**: HTTP/2 allows multiple concurrent gRPC requests and responses to be sent over a single TCP connection. This eliminates head-of-line blocking and reduces connection overhead.
• Mention **Header Compression (HPACK)**: HTTP/2 compresses request and response headers, reducing the overhead, especially for RPCs with frequent metadata exchanges.
• Describe **Binary Framing**: HTTP/2 frames all messages (headers, data) into binary format, which is more efficient for parsing and transmission than HTTP/1.1's text-based approach.
• Note **Server Push**: While less directly used by gRPC's core RPC model, HTTP/2 supports server push, which can be leveraged in certain advanced scenarios.

Where people lose the point

• ×Attributing HTTP/2 features solely to gRPC, rather than understanding HTTP/2 as the underlying enabler.
• ×Not understanding the fundamental differences between HTTP/1.1 and HTTP/2, especially regarding connection management.
• ×Missing multiplexing as a key benefit for concurrent RPCs.

What a strong answer covers

• Define gRPC interceptors as a mechanism to intercept and modify the behavior of RPC calls, similar to middleware in web frameworks.
• Explain their purpose: to add cross-cutting concerns (e.g., logging, authentication, metrics) without modifying the core service logic.
• **Client-side Interceptor Examples**: Adding authentication tokens to outgoing request metadata, implementing retry logic for transient failures, logging outgoing RPC calls, or adding tracing IDs.
• **Server-side Interceptor Examples**: Performing authentication and authorization checks before invoking the service method, collecting metrics on incoming requests, logging request details, or handling common errors.
• Mention that interceptors can be chained together, executing in a defined order.

Where people lose the point

• ×Confusing interceptors with the actual business logic of the gRPC service methods.
• ×Only providing examples for one side (client or server) or giving vague examples.
• ×Not understanding that interceptors operate *before* or *after* the actual RPC method execution, wrapping the call.

What a strong answer covers

• Utilize gRPC's rich status model: gRPC defines a set of canonical status codes (e.g., `OK`, `UNAUTHENTICATED`, `NOT_FOUND`, `INVALID_ARGUMENT`) that should be used to indicate the outcome of an RPC.
• Attach detailed error messages: Provide clear, human-readable error messages to aid debugging, but avoid exposing sensitive internal details.
• Use `google.rpc.Status` and `Any` type for richer error details: For complex error scenarios, gRPC allows attaching structured error details using the `google.rpc.Status` message and `Any` type, enabling clients to programmatically understand specific error contexts.
• Implement server-side error handling: Catch exceptions or errors within service methods and map them to appropriate gRPC status codes before returning.
• Implement client-side error handling: Clients should check the returned status code and handle different error types gracefully, potentially with retries or fallback logic.

Where people lose the point

• ×Relying solely on HTTP status codes, which gRPC abstracts away with its own status model.
• ×Returning generic error messages without sufficient context for debugging or client-side handling.
• ×Not considering how errors propagate and should be handled in streaming RPCs (e.g., closing the stream with an error status).

What a strong answer covers

• **Client-side Load Balancing**: The gRPC client itself is responsible for discovering available server instances and distributing requests among them. This often involves a resolver (e.g., DNS, Consul) to get endpoint addresses and a load balancing policy (e.g., round-robin, least-connections) implemented within the client library.
• **External Proxy/Load Balancer**: An external proxy (e.g., Envoy, NGINX, HAProxy) sits in front of the gRPC servers. It terminates the HTTP/2 connection from the client and then forwards requests to backend gRPC servers. This is common in Kubernetes environments with service meshes.
• **Trade-offs of Client-side**: Pros: Potentially lower latency (no extra hop), more intelligent routing decisions based on client context. Cons: Requires client-side logic, more complex to implement and manage across different client languages.
• **Trade-offs of External Proxy**: Pros: Simplifies client implementation, centralizes load balancing logic, easier integration with existing infrastructure. Cons: Adds an extra network hop, potential for increased latency, proxy must be HTTP/2 aware.

Where people lose the point

• ×Only describing one type of load balancing without acknowledging alternatives.
• ×Not mentioning the role of service discovery mechanisms (e.g., DNS, Kubernetes service discovery) in both approaches.
• ×Failing to discuss the pros and cons or trade-offs associated with each load balancing strategy.

What a strong answer covers

• **Leverage Protobuf's Compatibility**: Protocol Buffers are designed for compatibility. Adding new fields to messages is backward-compatible (old clients ignore new fields) and forward-compatible (new clients can read old messages if new fields are optional).
• **Avoid Breaking Changes**: Never change field numbers, change field types of existing fields, or remove existing fields. If a field is no longer used, mark it as `reserved` to prevent accidental reuse of its field number.
• **Package Naming for Major Versions**: For significant, breaking changes, introduce a new Protobuf package (e.g., `package myapp.v2;`) and potentially a new service name (e.g., `UserServiceV2`). This allows old and new versions of the service to coexist.
• **New Methods for New Functionality**: Instead of modifying existing RPC methods in a breaking way, add new methods for new functionality, especially if the input/output signature changes significantly.
• **Optional Fields and Default Values**: Use `optional` for new fields to ensure older clients can still process messages. Define clear default values for fields.

Where people lose the point

• ×Suggesting changing field numbers or types of existing fields, which breaks compatibility.
• ×Not considering the impact of changes on existing clients and services.
• ×Failing to mention the role of Protobuf's design (field numbers, optional fields) in enabling compatibility.

What a strong answer covers

• **Choose gRPC for**: Microservices communication (internal), high-performance requirements, real-time streaming (bidirectional, server-side), polyglot environments (language-agnostic), mobile backends (bandwidth efficiency), IoT devices (low overhead).
• **Choose REST for**: Public APIs, browser compatibility (direct browser support for HTTP/1.1 and JSON), simple CRUD operations, resource-oriented design, easy debugging with standard HTTP tools (curl, browser dev tools), caching at HTTP level.
• Highlight key differences: gRPC uses Protobuf (binary, schema-first) and HTTP/2 (multiplexing, streaming); REST typically uses JSON/XML (text-based, often schema-less) and HTTP/1.1 (request-response).
• Emphasize that the choice depends on the specific use case, performance needs, and ecosystem.

Where people lose the point

• ×Stating one technology is universally 'better' than the other without context.
• ×Not providing concrete, distinct use cases for each technology.
• ×Missing fundamental differences in serialization format or transport protocol.

What a strong answer covers

• Define gRPC metadata as a collection of key-value pairs associated with an RPC call, similar to HTTP headers.
• Explain that metadata is transmitted as HTTP/2 headers and is distinct from the actual message payload.
• Common uses include: carrying authentication tokens (e.g., JWTs), tracing IDs for distributed tracing, custom request headers, language preferences, or other contextual information.
• Mention that metadata is typically transient, associated with a single RPC call, and can be accessed by interceptors or the service implementation.

Where people lose the point

• ×Confusing metadata with the actual message payload (the Protobuf message).
• ×Not understanding its transient, per-call nature.
• ×Failing to provide practical examples of its usage.

What a strong answer covers

• **gRPC Channel**: A long-lived, logical connection to a gRPC server. It abstracts away the underlying network details, handling connection management, load balancing, and authentication. Channels are typically expensive to create and should be reused.
• **gRPC Stub (Client)**: The client-side interface generated from the `.proto` service definition. It provides methods that mirror the RPC methods defined in the service, allowing client applications to call remote procedures as if they were local functions.
• Communication flow: The client application calls a method on the stub. The stub serializes the request message using Protobuf and sends it over the channel to the server. The channel manages the HTTP/2 connection. The server receives, deserializes, processes, and sends back a serialized response, which the stub then deserializes for the client.

Where people lose the point

• ×Confusing a channel with a single RPC call; a channel can carry multiple RPCs.
• ×Not understanding that the stub is generated code that provides a type-safe API.
• ×Missing the role of serialization/deserialization that occurs between the stub and the channel.

What a strong answer covers

• **Deadlines**: A client can specify a maximum amount of time (a deadline) for an RPC to complete. If the server does not respond within this time, the RPC is automatically cancelled by the gRPC runtime on both client and server sides.
• **Cancellation**: Clients can explicitly cancel an RPC at any time. Servers can also cancel an RPC if an internal error occurs or if a deadline is missed.
• **Importance**: Deadlines prevent clients from waiting indefinitely for a response, improving system responsiveness and preventing resource exhaustion. Cancellation allows for graceful termination of long-running or unnecessary RPCs, freeing up server resources and improving overall system resilience.
• Mention that cancellation signals are propagated through the context object, allowing server-side logic to react and stop processing.

Where people lose the point

• ×Not understanding that deadlines are enforced by both the client and server, not just a client-side timeout.
• ×Confusing deadlines with simple network timeouts; deadlines are application-level.
• ×Missing the resource management and system resilience benefits of deadlines and cancellation.

What a strong answer covers

• Define gRPC Reflection as a standard gRPC service that allows clients to dynamically discover the services and methods exposed by a gRPC server at runtime.
• Explain that it enables clients to query the server for its `.proto` definitions, including message types and service descriptions, without needing the `.proto` files beforehand.
• **Usefulness**: It's invaluable for generic gRPC tools like `grpcurl` (a command-line tool for interacting with gRPC services), gRPC UI explorers, and proxy servers (e.g., Envoy) that need to understand the API of a gRPC service without compile-time knowledge.
• Simplifies development, debugging, and integration by providing introspection capabilities.

Where people lose the point

• ×Confusing gRPC Reflection with the `protoc` compiler or code generation.
• ×Not understanding its dynamic, runtime nature.
• ×Missing the primary benefit for tooling and introspection, especially in polyglot environments.

What a strong answer covers

• **Transport Security (TLS/SSL)**: gRPC has native support for SSL/TLS, which encrypts the communication channel and authenticates the server to the client. This is fundamental for protecting data in transit.
• **Authentication**: Verifying the identity of the client making the RPC call. This can be achieved using various mechanisms, often implemented via server-side interceptors, such as JWTs (JSON Web Tokens) passed in metadata, API keys, or mutual TLS (mTLS) for client certificate authentication.
• **Authorization**: Determining if an authenticated client has permission to perform a specific action or access a particular resource. This is typically implemented within server-side interceptors or the service logic itself, based on roles or permissions associated with the authenticated client.
• **Rate Limiting**: Protecting services from abuse and denial-of-service (DoS) attacks by limiting the number of requests a client can make within a given timeframe. This can be implemented via interceptors or an external proxy.
• **Input Validation**: Ensuring that all incoming request data conforms to expected formats and constraints to prevent injection attacks or unexpected behavior. This should be done at the service method level.

Where people lose the point

• ×Only mentioning encryption (TLS) and ignoring authentication and authorization as distinct security layers.
• ×Not understanding the role of interceptors in implementing application-level security concerns.
• ×Failing to distinguish between transport-level security (TLS) and application-level security (auth/authz).