When should HTTP 424 Failed Dependency be used, and how do you design a retry-safe API contract?

Scenario

A batch API validates an order, reserves inventory, and creates the order. If inventory reservation fails, order creation never runs. The interviewer asks you to design the error response and justify whether HTTP 424 is appropriate.

What this tests

Distinguishing standardized HTTP semantics from team-specific conventions.
Representing partial completion, skipped work, and unknown outcomes in a dependency graph.
Designing idempotency, retry conditions, and error details as one contract.

Model answer

The boundary of 424

424 (Failed Dependency) is defined by WebDAV RFC 4918: the method could not be completed because another operation failed. It is not a generic alias for every downstream service error. A non-WebDAV API may adopt 424, but its public contract must define the meaning, client behavior, and compatibility expectations.

Choosing a status code

412 Precondition Failed: a request precondition such as If-Match was not satisfied.
409 Conflict: the request conflicts with current resource state, such as an inventory version change.
424 Failed Dependency: this step explicitly depends on a failed step in the same request or workflow and therefore did not execute.
5xx: the server could not complete the request because of a service failure, not because the request relationship explains the blocked step.

Do not mechanically map a dependency's 500 to 424. First decide whether a step in this workflow was blocked and whether the client can take a different action because of that fact.

Response body and state machine

Use RFC 9457 Problem Details with stable type, title, status, and detail, plus extensions such as blockedBy, operationId, retryable, and completedSteps. Business extensions are part of the contract and need versioning.

json

{
  "type": "https://api.example.com/problems/failed-dependency",
  "title": "Order creation was blocked",
  "status": 424,
  "detail": "Inventory reservation failed",
  "blockedBy": "reserve-inventory",
  "operationId": "op_123",
  "retryable": true,
  "completedSteps": ["validate-order"]
}

Retries and unknown outcomes

Automatically retry only when retryable=true and the same idempotency key is used. If the connection drops after inventory reservation was committed, the client cannot call the timeout a 424 because the server outcome is unknown; it should query by operationId. A completed side effect cannot be rolled back by pretending a second request is new; provide compensation when the business requires it.

Common mistakes

Treating 424 as a universal status for all microservice errors.
Returning only prose with no stable error type or operation ID.
Retrying every 424 and creating duplicate reservations or orders.
Hiding an outage behind 424 so monitoring cannot separate workflow blocking from platform failure.

Follow-up questions

Can a batch request partially succeed?

Yes, but return per-item status, idempotency information, and dependency details. The batch HTTP status describes the aggregate result; it cannot replace item results. If the business requires atomicity, state whether all changes roll back or none are committed.

When is 409 better than 424?

Resource-version and inventory-state conflicts are current-resource problems and usually fit 409. Use 424 when the current step was skipped because another step in the same workflow failed.

What if the dependency returns 503?

If the current step is blocked and the contract treats that as a workflow dependency failure, 424 can carry the root cause in its details. If the service as a whole is unavailable, return 503 and use service-level signals such as Retry-After. Monitoring and client policies must distinguish the cases.

How do you test the contract?

Cover dependency success, rejection, timeout, connection loss after commit, duplicate idempotency keys, partial completion, and recovery queries. Assert status, Problem Details fields, terminal state, and side-effect count rather than only the HTTP number.

Scoring rubric

Passing

Accurately explains the WebDAV origin of 424, draws boundaries for 409, 412, and 5xx, and proposes an idempotency key plus unknown-outcome query.

Strong

Designs Problem Details extensions, partial-completion states, monitoring categories, and safe automatic-retry conditions.

Excellent

Justifies each choice using business atomicity, dependency graphs, compensation, and versioned contracts, while calling out compatibility risk when 424 is used outside WebDAV.

Answer strategy

First establish the status code's standard origin, then draw the step states and side-effect boundaries; finally make the decision concrete with a queryable, retry-safe error contract.

Sources

Status-code standard

RFC 4918: WebDAV (IETF)

HTTP semantics

RFC 9110: HTTP Semantics (IETF)

Error format

RFC 9457: Problem Details for HTTP APIs (IETF)