How does scaling affect data consistency?

Scaling directly affects data consistency, because once data is spread across servers, it becomes harder to guarantee that every node sees the same state of the database at the same moment.

#1. Vertical scaling

• Data lives on a single server, so consistency is preserved automatically, transactions run within one DBMS.
• There are almost no consistency issues, but there's a physical ceiling on growth.

Summary: consistency is high, but the scale is limited.

#2. Horizontal scaling (replication, sharding)

When data gets spread across several nodes, new risks appear:

a) Replication lag. With asynchronous replication, changes reach the replicas after a delay. As a result, different nodes can hold different versions of the data. Example: a user places an order, it already exists on the master, but it isn't on the replica yet.

b) Distributed transactions. With sharding, a single operation can touch several servers. To preserve atomicity, coordination is needed (e.g. a two-phase commit protocol), but this adds latency and error risk.

c) The CAP theorem. In distributed systems, you can't guarantee all three at once:

• Consistency,
• Availability,
• Partition tolerance. Scalable systems typically sacrifice strict consistency in favor of availability and speed.

#3. Practical tradeoffs

• Most systems choose an eventual consistency model, data can temporarily diverge but converges over time.
• Critical operations (money, transactions) use synchronous mechanisms, trading speed for accuracy.

Summary: The more a system scales horizontally, the harder it becomes to maintain perfect consistency. That's why architects choose a balance, between speed, reliability, and data accuracy.