While the CAP theorem describes how a system behaves during a network partition (P), the PACELC theorem extends this to describe what happens during normal operation (Else).

The acronym is broken down as follows:

• P: If there is a Partition...
• A: ...does the system choose Availability...
• C: ...or Consistency?
• E: Else (when there is no partition)...
• L: ...does the system choose Latency...
• C: ...or Consistency?

CAP theorem only covers the PAC part: "In the presence of a Partition, choose Availability or Consistency." PACELC adds the ELC part: "When the system is running normally (Else), choose between Low Latency or High Consistency."

• DynamoDB / Cassandra (PA/EL): During a partition, they choose Availability. During normal operation, they prioritize low Latency (using eventual consistency).
• Relational Databases with Synchronous Replication (PC/EC): They prioritize Consistency both during a partition (by refusing writes) and during normal operation (by waiting for all replicas to acknowledge).
• VoltDB / MongoDB (PC/EL): They prioritize Consistency during a partition, but may choose Latency during normal operations.

Architects must realize that even when the network is healthy, there is a cost to consistency. To ensure all nodes are perfectly synced, the system must wait for network round-trips, which increases latency. If you want sub-millisecond responses, you often have to sacrifice "strong" consistency.