Why a fast microservice can take down your whole company if it forgets to set a timer.
gRPC is a fast, efficient framework for microservices to talk to each other. However, by default, a gRPC call has no timeout. If Service A asks Service B for data, and Service B hangs (due to a database lock or bad loop), Service A will wait forever. If 1,000 users make a request, Service A will open 1,000 connections to Service B and wait forever on all of them, rapidly running out of memory and crashing. This creates a catastrophic cascading failure.
In gRPC, you don't just set a timeout; you set a Deadline (an absolute point in time). The genius of Deadlines is that they propagate across servers. If Service A gives Service B 500ms to respond, and Service B takes 100ms before calling Service C, Service B automatically passes the remaining 400ms deadline to Service C. If the clock strikes zero, every service drops the request immediately, freeing up resources.
// BAD: Calling gRPC without a deadline (Defaults to Infinity)
response, err := client.GetUser(ctx, &req)
// GOOD: Setting an absolute Deadline
// If the call takes longer than 500ms, it aborts instantly.
ctx, cancel := context.WithTimeout(context.Background(), 500*time.Millisecond)
defer cancel()
// The context (and deadline) is sent over the wire to the server!
response, err := client.GetUser(ctx, &req)
if err != nil {
return "Fallback User Profile"
}Adding strict deadlines requires you to build Fallback Logic. If the Auth Service times out, what do you do? Do you log the user out? Show a cached profile? Return a 503 error? Handling these partial failures gracefully takes significant engineering effort, but it is required to build resilient distributed systems.