In distributed systems, the trade-off isn't just a simple choice between strong and eventual consistency. While eventual consistency is fine for a social media like-counter, it's a non-starter for a bank ledger. Conversely, the strict serializability of traditional databases often imposes unacceptable latency for global applications. The reality is a spectrum of consistency models, each offering a different balance of performance, availability, and correctness.

The CAP theorem is essential, but it only describes a system's behavior during a network partition. The PACELC theorem, formulated by Daniel Abadi, extends this by considering the system's normal state. It forces a more complete discussion about system design.

This "Else" part is critical. For a global-scale application, network latency is a constant. PACELC forces you to decide: do you respond quickly with potentially slightly stale data (favoring Latency), or do you ensure the data is perfectly up-to-date, even if it means a slower response (favoring Consistency)?

A system designed for a social media feed is a classic PA/EL system. During a partition (P), it chooses availability (A) over consistency. In normal operation (E), it prioritizes low latency (L) by serving cached, slightly stale content. In contrast, a financial transaction processing system is a PC/EC system. It sacrifices availability during a partition (P) for consistency (C), and it accepts higher latency (C) in normal operation (E) to ensure correctness.

Between the extremes of strong and eventual consistency lie several formal models that provide useful, pragmatic guarantees for real-world systems.

Linearizability provides perfect, real-time ordering and is often what developers mean when they say "strong consistency." It's essential for operations that depend on a single source of truth, like claiming a unique username or managing inventory. However, achieving it across geographically distributed data centers is expensive and slow due to the coordination required.

This model is a powerful middle ground. It aligns with human intuition—effects don't appear before their causes. Systems can track these causal links using techniques like vector clocks, which act as a versioning system that captures dependencies between events. This is far more performant than linearizability because it doesn't require global consensus on the order of unrelated operations.

Sometimes, even causal consistency is more than what's needed. For many user-facing applications, the most jarring inconsistencies happen when a user's own actions seem to disappear. We can solve this with weaker, more targeted guarantees.

This is often achieved by routing a user's reads to the same replica that handled their recent write, or by briefly caching their writes on the client side. It provides a fluid user experience without requiring system-wide consistency.

Another approach is to define an acceptable level of staleness based on business needs, or Service Level Agreements (SLAs).

This provides a predictable and testable guarantee. An analytics dashboard might be perfectly fine with data that is a few minutes stale, allowing the system to serve reads from geographically close, highly available replicas without sacrificing too much freshness.

Choosing the right consistency model is a core task in system design. It requires a deep understanding of not just the technical options, but also the product's requirements and the user's expectations. There is no single best answer, only a series of trade-offs.