Principle
Fail work that cannot meet its useful deadline
Late work can consume real resources while producing zero useful result.
When it fits
- A request has waited so long that continuing to process it cannot meet the caller's deadline or service objective.
When to avoid it
- Some durable background jobs remain valuable after the requester waits; distinguish user deadlines from durable obligations.
Why it matters
Propagate deadlines into the processing path. Before starting or continuing expensive work, check whether enough time remains to deliver a useful result. If not, fail quickly or return an explicit degraded response so resources can serve work that still has a chance to succeed.
An example
Do not run a 30-second analysis when only two seconds remain before the user request times out.
Check your result
The system stops spending material work on requests that are already unable to create timely value.
Keep this limit in mind
- Some durable background jobs remain valuable after the requester waits; distinguish user deadlines from durable obligations.
Connected ideas
Useful withOpen the circuit when a dependency keeps failing
Evidence and sources
Fail-fast strategies release resources when a request cannot succeed within the required service objective instead of allowing doomed work to continue consuming capacity.
Failing fast is inappropriate when partial or delayed completion still has required value.
REL05-BP04 Fail fast and limit queues · Fail fast desired outcome
Google SRE recommends small queues or early rejection under steady overload because long queues add latency, memory use and work that may already have missed its deadline.
Bursty asynchronous workloads can legitimately benefit from larger queues when backlog remains useful.
Addressing Cascading Failures · Queue management and latency/deadlines