404 vs 500: missing resource vs server failure

WHAT THIS TESTS This checks that you correctly separate 4xx errors (the client's request is the problem) from 5xx errors (the server failed), which drives both client behavior and alerting.

A GOOD ANSWER COVERS When GET /products/999 targets a product that does not exist, the right code is 404 Not Found. The request was well formed, but the resource simply is not there, a client-side situation the client can handle, for example by showing 'not found'. When the database connection fails mid-request, the right code is 500 Internal Server Error, because the failure is on the server and unrelated to the client's input; a 503 Service Unavailable is appropriate if the outage is transient or the service is overloaded, optionally with a Retry-After header. The distinction matters: 4xx tells the client to fix its request, 5xx tells the client the server is at fault and the request may succeed if retried later, and it should trigger server-side alerts.

COMMON WRONG ANSWERS Returning 500 for a missing record, which falsely signals a server bug and pollutes error dashboards. Returning 404 for a database outage, which hides a real incident. Returning 200 with an empty body for a missing resource. Returning 400 (Bad Request) for a non-existent id when the id itself was syntactically valid.

LIKELY FOLLOW-UPS When would 503 be better than 500? What about 410 Gone? How do these codes affect retries and monitoring? Should error bodies include a machine-readable error code?

ONE CONCRETE EXAMPLE if (!product) return res.status(404).json({ error: 'product not found' }); handles absence, while a caught database error does res.status(500).json({ error: 'internal error' }). A monitoring system can then alert on a spike of 500s (real incident) while ignoring routine 404s, which would be impossible if both returned the same code.