RFC 9110 defines 3 distinct success codes for DELETE, and choosing the wrong one breaks client state machines in distributed systems the 3 HTTP status codes and when staff engineers use each: 1. 204 No Content (synchronous completion, no body): the standard default. the resource was physically or logically removed during the request window, and the server has nothing to return. saves serialization overhead and bandwidth on mobile/high-throughput clients 2. 200 OK (synchronous completion with tombstone/snapshot): used when the client needs the final state of the deleted entity—such as an audit payload, cascade summary (`{"deleted_children": 14}`), or soft-delete tombstone with `deleted_at` timestamps for optimistic cache invalidation 3. 202 Accepted (asynchronous / background deletion): the most critical code for distributed architectures. if deleting a workspace, large database partition, or cloud resource kicks off background worker queues (draining replicas, orphan cleanup), returning 200/204 is an architectural lie. return `202 Accepted` with a `Location` header pointing to a job status URL (`/tasks/{job_id}`) bonus for idempotency: if the resource is already deleted, return `404 Not Found` (or `410 Gone` if permanently purged) to inform the caller the URI no longer maps to an existing resource