Request Deadline

A request deadline defines the maximum total time allowed for an operation to complete. It bounds end-to-end latency so a caller does not wait indefinitely for a slow or stuck operation.

A request deadline is a time budget attached to an operation. The budget starts when the operation begins and expires at a specified point in time. If the operation has not completed by then, it should be stopped, failed, or otherwise treated as timed out.

A deadline differs from a timeout because a deadline represents an absolute end time, while a timeout is usually a duration such as 500 milliseconds. A deadline can be propagated to downstream services so that the entire request chain shares one remaining time budget.

In a Java backend, deadlines are useful for preventing blocked threads, excessive resource consumption, and cascading latency. The application should handle expiration explicitly and return an appropriate failure rather than continuing work that can no longer satisfy the caller's time budget.

Deadlines are especially important in distributed systems. If service A has only 200 ms remaining, it should not give service B a fresh 500 ms timeout, because B could continue working after A's caller has already given up.

Key points

Interview questions

How should retries interact with a request deadline?

Retries must share the original request's remaining time budget rather than resetting the clock for every attempt. Before each retry, the service should calculate how much time remains and determine whether another attempt can finish meaningfully. A retry policy may also use exponential backoff, but the backoff itself consumes the deadline budget. This prevents retries from turning a bounded request into an unexpectedly long operation.

What is a request deadline?

A request deadline is the latest time at which an operation is allowed to complete. It prevents a request from waiting forever on slow or unavailable work. Once the deadline is exceeded, the operation should be treated as failed or cancelled. In distributed systems, the remaining budget can be passed to downstream services.

Why are deadlines important in a distributed Java service?

A distributed request may call several services, databases, or external APIs, each of which can become slow. Without an end-to-end limit, a request can consume threads and connections long after the caller has stopped waiting. A shared deadline lets each component know how much time remains. This helps limit resource usage and reduce cascading latency.

What is the difference between a deadline and a timeout?

A timeout is commonly represented as a duration, such as 200 milliseconds from the moment an operation starts. A deadline is an absolute expiration point, such as a specific instant in time. An end-to-end request can have one deadline while each downstream operation calculates its own remaining timeout from that deadline. This prevents downstream calls from accidentally extending the overall request beyond the caller's budget.

What should happen when a request deadline expires while a downstream call is running?

The application should attempt to cancel the downstream operation when the client no longer has a useful time budget. The Java implementation depends on the client library, but the important property is that cancellation or timeout propagates rather than allowing useless work to continue indefinitely. The service should also release resources such as threads, connections, and request-scoped state. If cancellation is not possible, the operation should still stop waiting and return a timeout-related failure when appropriate.