Sharding hard
Why is the classic 'Two-Phase Commit' (2PC) protocol generally considered a 'scalability killer' in large sharded database clusters?
- A It requires the use of IPv6 and specialized network hardware to coordinate the voting phase.
- B It provides 'Snapshot Isolation' which is fundamentally incompatible with sharded row-level locking.
- C It creates a massive security hole where any node can masquerade as the central coordinator.
- D It is a synchronous, blocking protocol. If even one shard is slow or temporarily unreachable, the entire cluster faces a 'Lock Exhaustion' crisis, hanging all other shards.
Answer: D. It is a synchronous, blocking protocol. If even one shard is slow or temporarily unreachable, the entire cluster faces a 'Lock Exhaustion' crisis, hanging all other shards.
As you add more nodes to a cluster, the probability that at least one node is experiencing a performance 'blip' (like a Garbage Collection pause) increases toward 100%. Because 2PC requires *unanimous* agreement from all participants, the latency of a transaction is determined by the *worst-performing* node ($P100$). Furthermore, shards hold locks on data while waiting for the final 'Commit' command from the coordinator. In a large system, this leads to 'Cascading Wait' where one slow node causes locks to pile up across the entire cluster, eventually bringing the system to its knees.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- In an E-Commerce platform, why might you choose to shard the `Orders` table by `user_id` rather than the more obvious `order_id`?
- In the context of database scaling, what is the fundamental difference between 'Vertical Partitioning' and 'Horizontal Partitioning' (Sharding)?
- If Shard A fails in a large cluster, and its incoming traffic is automatically re-routed to Shard B, what is the risk of a 'Cascading Failure'?
- In a standard 'Modulo Sharding' setup (`key % N`), what is the primary consequence of adding a new server to the cluster (increasing N from 10 to 11)?
- From an engineering perspective, when should you choose 'Vertical Scaling' (a bigger server) over 'Horizontal Scaling' (Sharding)?
- Which sharding strategy is mathematically optimized for efficient 'Range Scans' (e.g., retrieving all records created between January and March)?