A team is hitting a database bottleneck and has proposed sharding. How would you decide whether sharding is the right move, and what would you do instead if it is not?

1. Diagnose the bottleneck before choosing a fix: measure read versus write ratio, working-set size versus RAM, and whether the primary is saturated on CPU, IO, or connections. 2. Establish the ordering: caching first, then read replicas, then sharding — sharding last because it is the only one that changes the application's data model. 3. Explain why replication does nothing for write volume: every replica applies every write, so the write ceiling is unchanged. 4. Reach for replication when the workload is read-heavy (feeds, catalogues, dashboards), and note the bonus of a standby for failover. 5. Reach for sharding only when write throughput or raw data size physically exceeds one machine. 6. Name the costs sharding imports: choosing a shard key, cross-shard queries and joins, hot partitions, resharding, and loss of cross-shard transactions. 7. Describe the mature end state: shard first, then replicate within each shard, so writes scale horizontally and each shard survives a node loss. 8. Handle read-after-write consistency once replicas are in play — route the reader to the primary or to a replica known to have caught up.