Resilient System Design: Handling Unreliable External APIs and Partial Failures
When a platform sends a stock-purchase request to a broker API, it cannot know what happened merely because the connection ends badly. The broker may have received and executed the order before the response timed out. This design makes one synchronous attempt, records its outcome, and uses PostgreSQL to reconcile uncertain transactions in the background. The important boundary is between a response received from the broker and no response received. When the broker returns a response, the platform preserves the normal behavior: it stores the outcome and returns the broker’s 2xx or 4xx result to its client. A timeout, a server-closed socket, or a 5xx response is not treated as a failed purchase. It is treated as an UNKNOWN purchase that must be reconciled. ...