General Interview: How Should You Explain HTTP 507 Insufficient Storage?

Prompt and context

This HTTP and API fundamentals prompt fits backend, platform, SRE, and infrastructure roles. A request would be valid in principle, but the server cannot store the resulting resource state because a quota, filesystem, memory budget, or application limit is exhausted. Explain when 507 is meaningful, when another status is more accurate, and how to recover without duplicating a write.

What the interviewer is assessing

• Can you separate server-side capacity exhaustion from a request that is intrinsically too large?
• Do you know that 507 originated in WebDAV and is a temporary server condition rather than a generic validation error?
• Can you define retry, backoff, idempotency, and user-facing remediation without hiding the cause?
• Can you trace the limit across application, storage, quota, proxy, and cache layers?

Clarifying questions to ask

Ask which operation failed, whether the requested representation is valid, which resource limit was reached, whether the limit is tenant-specific, and whether the operation has already committed partial state. Confirm whether the client can retry safely and whether the service exposes a quota or capacity signal. If the payload exceeds a policy or parser limit regardless of free capacity, use 413; if the service is temporarily unavailable for broader processing reasons, 503 may fit better. Do not select 507 only because a disk alert exists somewhere in the fleet.

A 30-second answer framework

I would return 507 when the requested operation is otherwise valid but the server cannot record the resulting resource state because available storage or an applicable server limit is exhausted. I would distinguish it from 413, which is about the request being too large, and from 503, which represents broader temporary unavailability. The response should expose a stable error type and request ID without leaking internal paths. The client retries only when the operation is idempotent or has an idempotency key, with bounded backoff; the operator measures the exact exhausted dimension, frees or expands capacity, and verifies a complete write before declaring recovery.

Step-by-step deep dive

1. Classify the failure. RFC 4918 defines 507 for a method that cannot record the resource state after execution because the destination lacks sufficient space. MDN notes that implementations also use it for exhausted server resources or application limits. The key condition is a valid action blocked by a server-side capacity boundary.
2. Separate neighboring statuses. Return 413 when the content is too large independent of current capacity. Return 409 or 412 when a state conflict or precondition fails. Return 503 when the service cannot process requests generally and may provide Retry-After. A 507 response should not become a catch-all for every write failure.
3. Make the failure actionable. Use a stable problem type, human-readable title, request ID, and a retry hint only if capacity is expected to recover. Tenant quotas may include a safe quota identifier or remediation link, while filesystem paths, hostnames, and secret policy details stay internal.
4. Protect retries. A timed-out upload can have unknown commit state. Require an idempotency key or resumable upload token, persist the operation state, and make the client query status before replaying. Apply exponential backoff with a deadline; unlimited retries can amplify a full system.
5. Trace the resource boundary. Record free bytes or inodes, object-store quota, database/blob staging usage, memory limit, tenant allocation, and the layer that emitted 507. Compare application logs with storage metrics and request IDs so a proxy-generated error is not mistaken for an origin decision.
6. Recover and verify. Drain or reject new writes if needed, expand or reclaim capacity, and re-run a bounded write using the original idempotency key. Verify the object checksum, metadata, visibility, and quota accounting. Alert on recurrence and test that a full tenant cannot consume another tenant's reservation.

Example of a strong answer

I would use 507 only when the request is valid but the server cannot persist the resulting state because a storage or server resource limit is exhausted. A payload that is always too large is 413, and a broad maintenance or overload condition may be 503. I would return a stable problem type and request ID, plus a retry hint only when recovery is plausible:

HTTP/1.1 507 Insufficient Storage
Content-Type: application/problem+json
Cache-Control: no-store
Retry-After: 120

{
  "type": "https://api.example.com/problems/storage-exhausted",
  "title": "The resource could not be stored",
  "status": 507,
  "detail": "The workspace storage limit prevented this operation.",
  "request_id": "req-7f2"
}

The client must not blindly resend an upload whose commit state is unknown. It retries with the same idempotency key or asks for operation status first. Operators correlate the request with quota, staging, object-store, database, and inode metrics, then verify checksum, visibility, and accounting after capacity is restored. If a gateway emits 507 while the origin returns 200, I treat the gateway as the emitting layer and test each hop independently.

Common mistakes

• Returning 507 for an oversized request → capacity changes cannot make that payload valid → use 413 for a fixed request-size policy.
• Retrying every 507 immediately → a full resource becomes more contended → use bounded backoff and an operation deadline.
• Replaying an upload after a timeout → the original write may have committed → query status or reuse an idempotency key.
• Saying “the disk is full” without locating the boundary → quotas, inodes, staging, and object storage can fail independently → identify the emitting layer and exhausted dimension.
• Reporting raw paths and hostnames to clients → internal topology and tenant data may leak → return a stable problem type and request ID, while keeping diagnostics in protected logs.

Follow-up questions and answers

Should a client retry HTTP 507?

Only when the operation is safe to retry and capacity is expected to recover. Use an idempotency key or status lookup for writes, exponential backoff, and a deadline. If the error represents a hard tenant quota, surface remediation instead of retrying.

How do you tell 507 from 503?

507 identifies inability to record a valid resource state because a storage or server limit is exhausted. 503 is a broader temporary inability to serve the request and may cover maintenance or overload. Use the measured failure boundary and consistent service policy rather than guessing from the HTTP layer alone.

What if the origin succeeded but a proxy returned 507?

Capture request IDs and compare origin-direct, proxy, and cache-cold requests. The proxy is the emitting layer and may have its own buffer or quota. Reconcile the client's final state before retrying, because the origin may already contain the resource.