A log viewer offers a comforting fiction: sort the rows by timestamp and the incident becomes a story. The rows line up. A request appears above a retry, an acknowledgment below a write, and a cause seems to have acquired an address. But a neat display is only as good as the relationship between the clocks and the events.
In a distributed system, an event can influence another through a message even when their wall clocks disagree about the time. Conversely, two events can receive conveniently ordered timestamps without either having influenced the other. The difference matters whenever we turn observation into explanation.
Begin with the message, not the dial
Leslie Lamport's 1978 paper on time and event ordering defines a happened-before relation using events within a process, message sending and receipt, and transitivity. That relation gives a partial order. Some events are concurrent in this technical sense because neither precedes the other through those relationships.
A logical clock can assign numbers consistent with that order. If one event happens before another, its logical timestamp is smaller. The converse does not follow: a smaller number alone does not prove that the first event causally preceded the second. Extending a partial order into a convenient total order does not manufacture the missing influence.
Imagine a hypothetical field notebook replicated between two stations. Each station independently labels a sample. Later, a courier carries one station's update to the other. Receipt gives the receiving station information it lacked before. A label written before that receipt cannot have been chosen in response to the arriving update, however pleasingly the wall-clock times line up afterward.
The example is small enough to draw on paper. Two vertical lines represent the stations and an arrow represents the courier's message. The interesting structure is the arrow. A sort order printed beside the drawing can help us read it, but it cannot replace it.
Concurrency is missing knowledge
This is a more useful understanding of concurrency than imagining events that occur at exactly the same physical instant. Two edits can be concurrent because they were made without the relevant knowledge of each other. They may be separated by minutes and still require reconciliation when their histories meet.
The original Dynamo paper describes using vector clocks to relate object versions and distinguish causal descendants from versions requiring reconciliation. It is a historical account of the system presented in 2007, not a statement about the behavior of today's similarly named services. Its importance here is the decision to retain information about version relationships rather than hiding every difference behind a single newest-looking value.
Back at the fictional stations, independently correcting the same label produces two meaningful versions. A total order can select one for display. Version relationships can reveal why that selection does not settle the conflict. The information that no update knew about the other is useful precisely because no timestamp-based story can supply a missing consultation.
There is a cost to carrying richer history, and particular systems bound or summarize it. The general lesson is not that every object needs the largest possible clock. It is that an application should know which questions its recorded history can answer. Compactness purchased by discarding relationships may be reasonable, provided nobody later promises to reconstruct those relationships from a date field.
Three different kinds of order
Once ordering becomes explicit, some familiar guarantees become easier to distinguish. Causal ordering concerns influence. A serial order concerns the effects of transactions as if they ran one at a time. Real-time constraints additionally care about the relationship between operations that finish and operations that begin afterward. These are related subjects, rather than interchangeable labels.
Jepsen's account of linearizability describes operations appearing atomic in an order consistent with real-time precedence, and notes that the object over which a system offers this guarantee can vary. A promise about one key cannot simply be extended to an entire workflow spanning unrelated keys. Scope belongs in the statement of the guarantee.
PostgreSQL's transaction-isolation documentation describes serializable transactions in terms of effects consistent with serial execution, including the need to handle serialization failures and retry. That is a useful contrast. A serial explanation of committed transactions is not the same thing as taking timestamps from arbitrary services and believing that they provide a universal narrative of everything the application did.
For the imagined stations, a database transaction can keep a local set of records consistent. It cannot retroactively make a remote scientist aware of information that had not arrived. The system boundary determines which ordering tools are relevant to which promise.
Read an incident as a graph
A practical exercise follows from this distinction. Choose a short invented incident and record send, receive, begin, and completion events separately. Add request identifiers and explicit links where the system actually transmits information. Only then place the wall-clock observations beside the events. This is a proposed way to reason, not a report of a measured debugging improvement.
The graph may leave some pairs unordered. That is useful information. It tells the investigator which conclusions require another observation. Filling those gaps with a confident narrative would be easier, but it would also erase uncertainty that belongs to the evidence.
A timestamp remains valuable. Physical time helps describe latency, correlate with external events, and investigate deadlines. It just needs to remain a measurement with conditions, rather than becoming an all-purpose witness. Logical ordering has conditions too. Neither earns trust by sounding more mathematical than the other.
The field notebook eventually comes back into agreement. A good account of how it got there would retain the messages, the independent decisions, and the later reconciliation. The sorted log is a useful reading aid. The causal story lives in the connections between its rows.
A thought worth keeping?
