Carry a time budget across different clock domains

On one host, an absolute local deadline can be represented as a suitable elapsed-clock reading plus a duration. Comparing later readings against that same deadline avoids repeatedly granting a fresh timeout after interruptions or retries. The epoch and semantics are part of its type, even if the programming language stores everything in the same integer. A reading from another machine, a wall-time clock, or a previous boot is not interchangeable. Include suspension behavior and rate assumptions when the real requirement is elapsed physical time rather than merely progress of one chosen local clock.

A remaining-duration budget can cross hosts without requiring equal monotonic epochs. The receiver establishes its own local deadline using that duration and its own appropriate clock. However, duration propagation is not free passage through the network: serialization, transit, queueing, and dispatch consume end-to-end time. Transport libraries have particular deadline-propagation and cancellation rules; inspect their actual contract. If a protocol cannot bound or account for a stage, it cannot prove an exact cross-host physical deadline solely by sending a number of milliseconds. The caller can still enforce when it stops waiting, while downstream cleanup remains a separate obligation.

When a service starts a downstream call, derive its budget from the parent's remaining time instead of reusing the original request timeout. Reserve time for required return handling, local cleanup, and any modeled communication margin. Clamp negative results to zero and fail or cancel according to the application's contract rather than letting an unsigned subtraction create an enormous timeout. Parallel subcalls can share a common parent deadline; sequential retries consume the same shrinking budget. A per-attempt cap may further restrict each try, but it must not extend the parent deadline.

Absolute wall-time propagation is another possible protocol only when hosts share a sufficiently justified time scale and error contract. It needs conservative handling of the clock uncertainty that a raw date string hides. Relative propagation avoids the epoch comparison but still needs sensible accounting for time in transit and differences in elapsed-clock behavior. gRPC documents propagation using timeouts derived from deadlines and deducting time already elapsed; language support and application cancellation handling still matter. Read the generated or framework behavior in your stack rather than assuming that every child operation automatically inherits the request's entire lifetime policy.

An expired caller deadline can stop the local wait while the server is still executing or has already committed an effect whose response was lost. Cancellation is usually cooperative: expensive loops, external work, and cleanup paths must observe it through the runtime's supported mechanisms. It does not roll back an arbitrary database or external service action merely because the client no longer wants the reply. Keep operation identities and outcome-reconciliation rules for ambiguous completion. A retry after timeout can otherwise duplicate the effect while appearing to be a harmless continuation of the same user request.

The queue lab isolates why waiting work consumes useful time even when clock conversion is correct. Compare separate fixed-rate runs at arrival 4/service 2 and arrival 2/service 4. Before each, Reset, re-set both rates, predict growth or drainage from four requests, then Play or Step. The second fresh backlog reaches zero after two seconds in this fluid model; it does not continue the first run's accumulated work. Neither trajectory implements deadlines, request identities, network transit, or cancellation. The narrower lesson is that preserving a budget numerically cannot supply missing service capacity or guarantee the completion time of an individual queued request.