Before consensus protocols in distributed systems and long before cluster manager frameworks or distributed process schedulers had emerged, we had clocks.
Say you have process running on systems that aren’t quiet aware of each other, and needs some ordering in the way they behave through asynchronous communication and network delays/faults. An event that causes another should ideally be processed before the result is, but this is not always the case. If you request an e-commerce app to add 10 bananas into your cart and then to check out, but the first request gets delayed and both reaches the server at the same time.. Do you checkout with no bananas? Each update/request event to a different node sends along a logical timestamp (physical is not practical, atomic clocks are a different matter), which is the number of ticks since the system started. The receiver confirms the event and updates its timestamp to max between current timestamp and (request timestamp+time for event), then sends success response. Lamport clock timestamps ensures causal ordering, if an event a causes event b, we can know that the timestamp for event a is less that that for event b.
Vector clocks are an extension to Lamport clocks, that instead of sending it’s own timestamp sends a vector of all its communication’s timestamp along with the event. Hence the receiver when getting the event can decide if it has an updated version of the event from another node. Vector are used in Amazon’s older dynamo data stores.