Keep your API fast—even at peak

Follow the caller separately from the database. Waiting for a result consumes time, but the caller’s decision to stop waiting does not by itself establish what happened to remote work.

At this starting snapshot, zero seconds have elapsed and thirty seconds remain. The bar represents the caller’s elapsed waiting time, not percent completion of a database operation.

This defines the event we will show next. The request is still waiting in the starting snapshot; when its budget is exhausted without the expected answer, the caller times out.

The caller remains visibly pending. Only five of the thirty seconds have elapsed, leaving twenty-five. Nothing in this snapshot says a report was delivered or that the database finished.

The failure is shown on Maya’s caller, not as an error response supposedly sent by the database. The caller reached thirty seconds without its expected report; this is not a successful completion.

The separate database track remains unresolved. A caller timing out does not automatically cancel the database operation, stop its resource use, or establish whether a write took effect.

This is a separate signal asking the operation to stop, not an automatic consequence of the earlier timeout. Each component must propagate or handle cancellation and the downstream operation must actually honor it.

The application and database exchange calls and answers over a connection. A connection’s condition is a different fact from the caller’s waiting budget or the database operation’s final outcome.

A broken connection may report an error immediately, without consuming the full thirty-second waiting budget. A fast communication error still does not automatically prove that remote work had no effect.

No. The operation may still be running, may have stopped, or may have completed without its answer reaching the caller. A timeout does not prove that stored data stayed unchanged, or that a write was rolled back.