Replica set vs sharding — availability or splitting data?

A replica set keeps copies of the data: the primary accepts writes and secondaries replicate the changes. On failure, a new primary can be elected. Sharding splits data across shards and solves a different problem.

In practice: the application must cope with briefly losing the primary. I choose write concern, read concern and read preference to match the consistency and availability requirements.

Pitfall: a secondary can lag behind. Moving reads to replicas doesn't guarantee the latest write is visible immediately. Replication doesn't replace backups, and it doesn't make writes scale automatically across all nodes.