The reply happened first.

The setup

Service A sends a request to service B. B processes it and returns a reply. The services’ wall clocks disagree. Their logs share a reliable request identifier.

These are local wall-clock readings, not comparable instants: the example does not assign them a shared date or UTC offset. The record supports an order through message relationships and B’s local event order: A sent R before B received it; B received R before replying; A received the reply after B sent it. The B receive-to-reply edge relies on that local order evidence, not on the clock strings. Sorting all four rows by their wall-clock strings would not show the supported order.

A partial order is still useful

Request and reply identities can establish a causal sequence even when the clocks disagree. They do not, by themselves, place unrelated event C between two steps in that sequence. For C, the system needs more evidence: another message relationship, clock synchronization information with credible uncertainty bounds, or some other ordering constraint.

Even within one service, a wall clock can be adjusted. A local sequence number or monotonic clock can support local ordering without pretending to be a universal timestamp.

What a model would need to keep

Keep the original timestamps and their clock sources, the service identities, message and correlation IDs, and any local sequence or monotonic timing evidence. Record what each edge in the inferred order depends on. An honest answer can include “order unknown.”

Counterexamples wanted

• A retry or duplicate message that makes one request ID refer to several sends.
• A reply produced from a cache before the particular request was processed.
• A clock correction that moves wall time backwards within one service.
• A workflow that truly needs a total order even though the evidence only supports a partial one.