In this lesson, you will learn how the scope of atomicity changes when data is physically partitioned across multiple distinct servers.
When a database lives on a single server, the engine acts as the "source of truth." It tracks locks and log entries within one memory space, ensuring that if you update two rows, both either succeed or fail together. This is the bedrock of ACID atomicity.
However, in a sharded architecture, your data is distributed. If "User A" lives on Server 1 and "User B" lives on Server 2, a transaction that involves both users is no longer a local operation. The atomicity of that transaction is now split across two separate physical environments.
The Scope of Distributed Atomicity
Because Server 1 cannot "see" the lock table on Server 2, you lose the ability to perform a simple BEGIN and COMMIT that covers both. If the network drops or Server 2 crashes after the first half of your update completes, Server 1 might have already committed its portion.
Consider a simple bank transfer:
-- Server 1 (Shard A)
UPDATE accounts SET balance = balance - 100 WHERE user_id = 'Alice';
-- Server 2 (Shard B)
UPDATE accounts SET balance = balance + 100 WHERE user_id = 'Bob';
If these execute independently, the transaction is not atomic. If Server 2 fails before applying the credit, $100 effectively vanishes from the system. Because the shard boundary acts as a hard wall for transaction management, the "scope" of atomicity is limited to the individual shard.
To bridge this gap, you must move from local engine-level control to distributed coordination. You have to ensure that all participating shards agree on the final outcome, usually by using protocols like Two-Phase Commit (which you’ve seen before) or Sagas. Without these higher-level abstractions, your database effectively treats these two updates as completely unrelated operations, sacrificing global atomicity to maintain the performance benefits of sharding.
Key Takeaway: In a sharded database, the scope of atomicity is physically restricted to a single shard, meaning cross-shard operations lose native ACID guarantees unless managed by an external coordination protocol.