What is true about high availability and sharding?

What is true about high availability and sharding?

• A. Sharding and high availability are always tied together.
• B. Single-instance HA with read replicas is impossible without sharding.
• C. Running a primary database with read replicas can achieve high availability without sharding.
• D. Sharding is recommended for any HA deployment.

Answer: (C)

High availability means keeping the service up and responsive even when some parts fail, by adding redundancy and automatic failover. Sharding, on the other hand, splits data across multiple machines to improve write throughput and scale storage, but it isn’t required to stay available. You can achieve high availability with a single primary database plus read replicas. The primary handles writes, the replicas serve reads, and an automated failover mechanism can promote a replica to primary if the original fails. This setup preserves availability without needing to shard the data across multiple primary nodes. Of course, there are trade-offs to consider: replicas can lag behind the primary, so reads from replicas might see slightly stale data; failover timing and whether replication is synchronous or asynchronous affect data safety and latency. The other statements imply constraints that aren’t necessary: you don’t have to shard to achieve HA, and HA can be implemented without linking it inherently to sharding; likewise, saying sharding is recommended for every HA deployment adds unnecessary complexity unless your workload specifically needs distributed writes.

High availability means keeping the service up and responsive even when some parts fail, by adding redundancy and automatic failover. Sharding, on the other hand, splits data across multiple machines to improve write throughput and scale storage, but it isn’t required to stay available.

You can achieve high availability with a single primary database plus read replicas. The primary handles writes, the replicas serve reads, and an automated failover mechanism can promote a replica to primary if the original fails. This setup preserves availability without needing to shard the data across multiple primary nodes. Of course, there are trade-offs to consider: replicas can lag behind the primary, so reads from replicas might see slightly stale data; failover timing and whether replication is synchronous or asynchronous affect data safety and latency.

The other statements imply constraints that aren’t necessary: you don’t have to shard to achieve HA, and HA can be implemented without linking it inherently to sharding; likewise, saying sharding is recommended for every HA deployment adds unnecessary complexity unless your workload specifically needs distributed writes.