A client sees a timeout while the server is still processing an order. It cannot know whether to retry, wait, or tell the user to check later. Blind retries can duplicate side effects; refusing to retry can leave a legitimate request stranded.
The scenario
Design a request lifecycle for timeouts and partial failures. Include idempotency, status polling, bounded backoff, circuit breakers, dead-letter handling, and logs that connect the original request to every retry.
The question
When should a service return 202 rather than 200, and how can a client recover after a process restart?
The official solution is not published yet.Think it through with the community first.
Community discussion
0 contributionsBe the first to share your reasoning.