Distributed systems face the CAP trade-off: Consistency (every read returns the latest write), Availability (every request gets a response), and Partition Tolerance (system operates despite network splits). In practice, choose CP (consistent, may be unavailable during partitions) or AP (available, may return stale data). BASE (Basically Available, Soft-state, Eventual consistency) is the AP model. Strong consistency (linearizability) is the CP model. Most systems use a mix — strong for transactions, eventual for read replicas.
How an AP system converges to consistency after a write.
Every distributed system implicitly chooses between consistency and availability. Making this choice explicit per-service (payment service → CP, view counters → AP) prevents subtle and hard-to-debug data inconsistency bugs.
A common pattern: writes go to a strongly consistent primary, reads from eventually consistent replicas. Use session tokens to detect replica lag and route to primary when read-your-writes is required.
Google Docs, Figma, and linear apps use CRDTs to allow concurrent edits without locks. OR-Set for collaborative lists, G-Counter for distributed counters. No conflict resolution logic in application code.
Sign in to share your feedback and join the discussion.