Distributed systems theory provides vocabulary and frameworks for the trade-offs that database and service design involves. The CAP theorem is the starting point; PACELC is the more complete picture.
CAP theorem in practice
The CAP theorem states that a distributed system can provide at most two of: Consistency (every read receives the most recent write), Availability (every request receives a response, not an error), and Partition tolerance (the system continues operating despite network partitions). Since network partitions are inevitable in distributed systems, the real choice is between consistency and availability during a partition. Most databases choose one of these: CP (HBase, Zookeeper) or AP (Cassandra, CouchDB).
PACELC: latency in the normal case
PACELC extends CAP to consider the latency-consistency trade-off in the normal (no partition) case. A system can be: PA/EL (available during partition, low latency normally, Cassandra, DynamoDB), PC/EC (consistent during partition, consistent normally, HBase, Zookeeper), or PA/EC (available during partition, consistent normally, some configurations of Cosmos DB and Aurora). The choice is not just about partition handling; it is about latency vs consistency in the common case.
Eventual consistency in production
Eventual consistency means that in the absence of updates, all replicas will eventually converge to the same value. In practice this means: reads may return stale data, concurrent writes to the same record may conflict and need resolution, and the application must be designed to tolerate this. The key design discipline: avoid business logic that requires reading your own writes immediately after writing (read-your-writes consistency), and implement conflict resolution for records written by multiple clients.
When to choose strong consistency
Strong consistency (linearisability) is appropriate when: incorrect stale reads have financial consequences (account balances, inventory quantities), when the business process requires reading the result of a previous write (create order, immediately confirm with updated order status), or when audit requirements demand read-your-writes accuracy. Strong consistency typically costs latency (synchronous replication to quorum before acknowledging write). Understand the staleness tolerance of each data access pattern before choosing a consistency level.