Strong Consistency

Strong consistency describes a data-access guarantee: once a write completes successfully, a subsequent read within the covered scope must reflect that write or a later write. In distributed systems, this is commonly expressed as linearizability: operations appear to occur atomically in a single order that respects their real-time completion. If a read overlaps a write, either the previous value or the new value may be valid, depending on where the operations fall in that order.

For example, an application changes an account’s notification preference and receives a successful response. A strongly consistent read started afterward must not return the preference that existed before that update, unless another write has restored it. This guarantee applies to other clients too; it is stronger than merely allowing the writing client to read its own changes.

Eventually consistent reads can temporarily return older data while replicas catch up. If updates stop and replication continues successfully, the replicas eventually converge. Eventual consistency can be appropriate for activity feeds or noncritical dashboards, whereas strong consistency is useful when a workflow must immediately verify a completed update. The choice should follow the application’s correctness requirements rather than a blanket preference for one model.

Cloud databases implement these guarantees through mechanisms such as leader coordination, replication protocols, and quorum-based decisions. The guarantee belongs to a documented operation and scope, not automatically to every endpoint, index, cache, or Region associated with the service. A strongly consistent database read cannot make an application cache current. Similarly, an asynchronously updated search index can remain stale even when its source database supports strong reads.

Amazon DynamoDB illustrates an explicit read-consistency choice. Reads are eventually consistent by default; supported operations can request strong consistency with ConsistentRead set to true. Tables and local secondary indexes support strongly consistent reads, but global secondary indexes do not. For the same item size, a strongly consistent read consumes twice the read capacity of an eventually consistent read. Cross-Region expectations must also match the configured global table consistency mode rather than being inferred from a local read setting.

Strong consistency does not prevent read-modify-write races. Two checkout workers can both read that one unit remains and both attempt to sell it. A conditional update that decrements stock only when sufficient inventory remains prevents this race; a transaction may be needed when several records must change together. Likewise, individually strong reads across a scan do not necessarily provide a single point-in-time snapshot of the entire dataset. Database consistency should not be confused with the consistency property of ACID, which concerns preserving application invariants.

The trade-offs include coordination overhead, potentially higher latency, and sometimes higher request cost. During a network partition, a system preserving linearizability cannot also guarantee successful operations on every disconnected side; it may reject or delay requests rather than serve stale data. Strong consistency also does not mean zero latency, synchronous replication to every replica, or automatic atomicity across multiple objects. In exam scenarios, identify whether immediate visibility is required, whether the selected access path supports it, and whether the real requirement also needs conditional writes or transactions.