Reliable APIs are designed for failure.
An API that only behaves correctly when every dependency is healthy is not reliable. It is optimistic.
Retries change the problem
Once a client can retry, every important write operation needs a clear answer to “what happens if the same request arrives twice?” Idempotency is business correctness, not a nice-to-have header.
Timeouts do not mean nothing happened
A timeout tells the caller that it does not know the result. It does not prove the operation failed. Systems need correlation, status visibility and safe recovery paths.
Observability should answer operational questions
Metrics and logs are useful when they tell the team what state the transaction is in, where it stopped and whether it is safe to continue. Technical telemetry without business context is incomplete.