What is a vector clock and how does it solve consistency problems?

A vector clock is a data structure for tracking causality and detecting concurrent events in distributed systems without a centralized clock. Each node maintains a vector of logical timestamps, one per node in the system. Structure: node A maintains VC_A = [A:2, B:1, C:0] — A is at time 2, last known B time is 1, last known C time is 0. Operations: (1) Internal event: increment local component: VC_A[A]++; (2) Send message: increment local component, attach VC to message; (3) Receive message: take element-wise maximum of local VC and received VC, then increment local component. VC_merge[i] = max(VC_local[i], VC_received[i]). Comparing events: event A happened before B (A → B) if VC_A[i] ≤ VC_B[i] for all i AND VC_A ≠ VC_B. Events are concurrent if neither precedes the other — some components larger, some smaller. Conflict detection: two writes are concurrent if their vector clocks are incomparable. The system can detect that a conflict exists and present both versions to the application for resolution. This is better than LWW (last-write-wins with timestamps) which silently discards data. Used in: Amazon DynamoDB (original), Voldemort, Riak. Dotted version vectors: improvement over vector clocks — avoids false conflicts by tracking which events caused each update. CRDTs (Conflict-free Replicated Data Types) go further — data structures designed so concurrent updates always merge without conflict (counters, sets, registers). Examples: G-Counter, OR-Set, LWW-Register. Used in collaborative editing (Google Docs), distributed databases, mobile offline sync.