Follow the Request
`POST /orders`, from a client you do not control to a response that may never be read. Open any step to go one layer deeper and to see what that step can fail at — because every hop here is a separate participant with its own timeout, its own limits and its own idea of what healthy means.
The reason to walk this end to end is that almost every confusing production incident is really a disagreement between two of these steps. A proxy that times out at 30 s in front of a handler that times out at 60 s means the second number never takes effect. A client that retries in front of a write that is not idempotent means the second charge is real. You cannot see either from inside the handler.
- One layer deeper
The client also decides retry behaviour. A mobile client on a flaky network may resend a request you already processed, which is why a retry-safe write is a client-driven requirement rather than an internal nicety.
What can go wrong here- — Sends malformed or hostile input
- — Retries a request that already succeeded
- — Disconnects before reading the response
Where to go next
The same request, but with something wrong with it.