Designing Idempotent API Endpoints
Network timeouts don't tell you whether the request failed before or after the server processed it, which means naive retry logic on a POST /charges or POST /orders endpoint can silently double-charge a customer or create duplicate orders. The fix is an idempotency key: the client generates a unique key per logical operation (not per HTTP attempt) and sends it in a header. The server checks whether it has already seen that key; if so, it returns the stored result of the original request instead of re-executing the operation. Implementation details matter more than the concept: store the key alongside a hash of the request body, so a client accidentally reusing a key with different parameters gets a 422 instead of silently returning the wrong response. Expire keys after a bounded window (24-48 hours is typical) rather than keeping them forever. And make the whole check-and-store step atomic against the operation itself, usually via a unique constraint in the same transaction that performs the write, or you've just moved the race condition instead of closing it.
Token bucket, fixed window, and sliding window each trade off burst tolerance against implementation cost differently. Picking the wrong one either blocks legitimate bursty clients or lets abusive ones through.
An N+1 query pattern looks completely reasonable in a diff — one clean loop over a list, one query inside it. The problem only shows up under realistic data volume, which most review environments don't have.
GraphQL solves a real problem — overfetching and underfetching across many client shapes. Most internal, single-client APIs don't have that problem, and adopt the complexity without the benefit.