What are gRPC interceptors and how are they used?
Learn what gRPC interceptors are, how unary and streaming interceptors wrap RPC calls, and how to use them for auth, logging, and metrics on client and server.
Expected Interview Answer
gRPC interceptors are middleware hooks that wrap RPC calls so you can run shared logic — like authentication, logging, metrics, or retries — before and after the actual handler executes, on both the client and server side.
They come in two flavours: unary interceptors that wrap single request/response calls, and streaming interceptors that wrap streaming RPCs. On the server they sit between the transport and your service method; on the client they sit between your stub call and the wire. Because they receive the call context, metadata, and a handler continuation, they can inspect or mutate the request, short-circuit it, or process the response, all without touching individual service methods.
- Centralizes cross-cutting concerns like auth and logging
- Keeps service methods focused on business logic
- Works on both client and server sides
- Enables consistent metrics, tracing, and error handling
- Composable — multiple interceptors chain in order
AI Mentor Explanation
Think of the third umpire and boundary technology sitting around every delivery: before a run counts, checks for no-balls and edges run automatically, and after the ball is dead, the score is logged. Interceptors wrap each RPC the same way, so validation and logging happen around every call without the batter or bowler doing anything extra themselves.
Step-by-Step Explanation
Step 1
Choose the interceptor type
Decide between a unary interceptor for single request/response calls or a streaming interceptor for streaming RPCs, and whether it runs on the client or server.
Step 2
Implement the wrapper function
Write a function that receives the call context, metadata, and a handler/invoker continuation, then run pre-processing logic before delegating.
Step 3
Call the continuation
Invoke the provided handler (server) or invoker (client) to execute the actual RPC, capturing its response or error.
Step 4
Run post-processing
After the continuation returns, log the outcome, record metrics, transform the response, or map errors as needed.
Step 5
Register the interceptor
Attach it when building the server or channel; multiple interceptors chain in the order they are registered.
What Interviewer Expects
- Knows interceptors are middleware around RPC calls
- Distinguishes unary vs streaming and client vs server interceptors
- Understands the handler/invoker continuation pattern
- Can name real use cases like auth, logging, and tracing
- Understands interceptor chaining order
Common Mistakes
- Confusing interceptors with the service handler itself
- Forgetting to call the continuation, silently dropping the RPC
- Assuming a unary interceptor also handles streaming calls
- Ignoring interceptor ordering when chaining multiple
- Putting business logic in an interceptor instead of cross-cutting concerns
Best Answer (HR Friendly)
“gRPC interceptors are like reusable checkpoints that every network call passes through, so common tasks such as logging in, recording metrics, and handling errors happen automatically. This keeps the main code clean because the shared work is done in one place instead of being repeated everywhere.”
Code Example
func LoggingInterceptor(
ctx context.Context,
req interface{},
info *grpc.UnaryServerInfo,
handler grpc.UnaryHandler,
) (interface{}, error) {
start := time.Now()
resp, err := handler(ctx, req) // call the actual RPC
log.Printf("method=%s duration=%s err=%v", info.FullMethod, time.Since(start), err)
return resp, err
}
server := grpc.NewServer(
grpc.UnaryInterceptor(LoggingInterceptor),
)Follow-up Questions
- How do unary and streaming interceptors differ in implementation?
- How do you chain multiple interceptors and control their order?
- How would you implement authentication using an interceptor?
- How do interceptors interact with gRPC metadata?
- How can a client interceptor implement automatic retries?
MCQ Practice
1. What is the primary purpose of a gRPC interceptor?
Interceptors are middleware that wrap RPC calls to run shared logic like auth and logging before and after the handler.
2. Which pair correctly describes interceptor categories?
gRPC provides unary interceptors for single call/response RPCs and streaming interceptors for streaming RPCs.
3. What happens if a server interceptor never calls the provided handler?
The handler continuation executes the actual RPC; skipping it short-circuits the call so the service method never runs.
Flash Cards
What is a gRPC interceptor? — Middleware that wraps RPC calls to run shared logic before and after the handler on client or server.
Two interceptor types? — Unary interceptors for single request/response RPCs and streaming interceptors for streaming RPCs.
Common interceptor use cases? — Authentication, logging, metrics, distributed tracing, retries, and error mapping.
How do multiple interceptors combine? — They chain and execute in the order they are registered, each wrapping the next.