gRPC Interview Questions India 2026: Protocol Buffers, Streaming, and Microservice Communication

gRPC basics:

1. What is gRPC? gRPC is a high-performance, open-source Remote Procedure Call (RPC) framework developed by Google (open-sourced 2016). It is widely used for inter-service communication in microservice architectures. gRPC uses: - Protocol Buffers (protobuf): a compact binary serialisation format (3-10x smaller than JSON; 3-10x faster to parse) - HTTP/2 as the transport protocol (multiplexed requests on a single connection, header compression, server push) - Strongly typed schema via .proto files (the client and server agree on the interface at compile time) - Code generation: protoc (the Protocol Buffer compiler) generates client and server code in multiple languages from the .proto file

2. Protocol Buffers (.proto file): ```protobuf syntax = 'proto3';

package payment;

// Service definition service PaymentService { rpc ProcessPayment (PaymentRequest) returns (PaymentResponse) {} rpc StreamTransactions (TransactionFilter) returns (stream Transaction) {} }

// Message definitions message PaymentRequest { string orderid = 1; double amount = 2; string currency = 3; string userid = 4; }

message PaymentResponse { bool success = 1; string transactionid = 2; string errormessage = 3; }

message Transaction { string id = 1; double amount = 2; int64 timestamp = 3; }

message TransactionFilter { string userid = 1; int64 fromtimestamp = 2; } ```

3. protobuf vs JSON: JSON: text-based; human-readable; schema is implicit; any field can be present or absent; larger payload. Protobuf: binary; not human-readable (requires a tool to decode); schema is explicit and enforced; unknown fields are silently ignored (backward compatible); 3-10x smaller; 3-10x faster to serialise/deserialise.

4. Field numbers: In protobuf, each field has a number (id = 1, amount = 2). These numbers are used in the binary encoding. Never change field numbers in a published .proto file (changing a number breaks backward compatibility). Adding new fields with new numbers is backward compatible. Removing fields: mark as reserved to prevent reuse.

gRPC communication patterns:

1. Unary RPC (request-response): The most common pattern. The client sends one request; the server sends one response. Equivalent to a single REST API call. ```protobuf rpc GetUser (GetUserRequest) returns (User) {} ```

2. Server streaming RPC: The client sends one request; the server streams a sequence of responses. The server keeps the connection open and sends messages as they become available. Use for: real-time stock price updates, live order tracking, search results (stream results as they are found). ```protobuf rpc WatchOrderStatus (OrderId) returns (stream OrderStatus) {} ```

3. Client streaming RPC: The client sends a stream of messages; the server sends one response (typically after the client is done sending). Use for: uploading a large file in chunks, batch inserting records. ```protobuf rpc UploadTransactions (stream Transaction) returns (UploadResult) {} ```

4. Bidirectional streaming RPC: Both client and server send streams of messages independently. The two streams are multiplexed over the same HTTP/2 connection. Each side can read and write in any order. Use for: chat applications, real-time collaboration, multiplayer games. ```protobuf rpc Chat (stream ChatMessage) returns (stream ChatMessage) {} ```

gRPC production patterns:

1. gRPC vs REST: | Feature | gRPC | REST | |---|---|---|| | Protocol | HTTP/2 | HTTP/1.1 or HTTP/2 | | Payload format | Protobuf (binary) | JSON (text) | | Payload size | Smaller (3-10x) | Larger | | Type safety | Compile-time (protoc generated) | Runtime (no contract enforcement) | | Streaming | Native (all 4 types) | Limited (SSE for server streaming; WebSocket for bidirectional) | | Browser support | Limited (requires gRPC-Web proxy) | Native | | Human readability | Not readable without tools | Human-readable JSON |

When to choose gRPC over REST: inter-service communication (microservices talking to each other internally); performance-critical paths (high-frequency calls where binary serialisation matters; streaming large data sets); strongly typed contract between teams (the .proto file is the contract; clients are regenerated when the contract changes).

2. gRPC error handling: gRPC defines its own status codes (Google's error model): OK (0), CANCELLED (1), UNKNOWN (2), INVALIDARGUMENT (3), NOTFOUND (5), ALREADYEXISTS (6), PERMISSIONDENIED (7), UNAUTHENTICATED (16), RESOURCE_EXHAUSTED (8), INTERNAL (13). The server returns a status code and a message; the client handles errors based on the code.

3. gRPC in Kubernetes: gRPC uses HTTP/2 connection multiplexing; this causes challenges with Kubernetes Services (L4 load balancer): a gRPC client opens one HTTP/2 connection to one pod and sends all requests on that connection (not load balanced). Solutions: use a service mesh (Istio, Linkerd) which operates at L7 and load-balances individual gRPC calls, or use a gRPC load balancer in the client (client-side load balancing with a service discovery integration).

4. gRPC-Web: gRPC-Web is a proxy layer that allows browser JavaScript to call gRPC services (browsers cannot use HTTP/2 framing directly). An Envoy proxy (or nginx with the grpc-web module) terminates gRPC-Web requests from the browser and forwards them as native gRPC to the backend.

gRPC advanced topics:

1. TLS in gRPC: gRPC uses TLS by default (HTTPS over HTTP/2). For inter-service communication inside a Kubernetes cluster, you can use insecure connections (grpc.WithInsecure()) if the network is trusted, but TLS is recommended (mutual TLS via a service mesh provides both encryption and identity verification between services).

2. gRPC interceptors (middleware): gRPC interceptors are the equivalent of middleware in REST frameworks. Unary interceptor: wraps all unary RPC calls. Stream interceptor: wraps all streaming calls. Common uses: authentication (verify the JWT token on every call), logging (log request method, duration, status code), metrics (count RPC calls and latency), rate limiting, distributed tracing.

```go func authInterceptor(ctx context.Context, req interface{}, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (interface{}, error) { token, err := extractToken(ctx) if err != nil { return nil, status.Errorf(codes.Unauthenticated, 'invalid token') } if err := validateToken(token); err != nil { return nil, status.Errorf(codes.Unauthenticated, 'unauthorized') } return handler(ctx, req) } ```

3. gRPC tooling: - grpcurl: command-line tool for interacting with gRPC services (like curl but for gRPC); uses server reflection to discover services without needing the .proto file. - Postman: supports gRPC as of 2022 (provides a GUI for calling gRPC endpoints). - Buf: modern protobuf toolchain (buf lint for protobuf linting, buf generate for code generation, buf push for publishing to the Buf Schema Registry).

4. Protocol Buffer versioning: Backward compatible changes (safe to add to a published .proto): adding new fields with new field numbers, adding new enum values, adding new RPC methods. Breaking changes (never do without versioning): removing fields or changing field types, changing field numbers, reordering enum values.