Where possible, consider deploying one member of each replica set
in a site suitable for being a disaster recovery location.

Sharding requires at least two shards to distribute sharded data. Single
shard sharded clusters may be useful if you plan on enabling sharding in
the near future, but do not need to at the time of deployment.

Deploying multiple mongos routers supports high
availability and scalability. A common pattern is to place a
mongos on each application server. Deploying one
mongos router on each application server reduces network
latency between the application and the router.

Alternatively, you can place a mongos router on dedicated
hosts. Large deployments benefit from this approach because it decouples
the number of client application servers from the number of
mongos instances. This gives greater control over the number
of connections the mongod instances serve.

Installing mongos instances on their own hosts allows these
instances to use greater amounts of memory. Memory would not be shared
with a mongod instance. It is possible to use primary shards
to host mongos routers but be aware that memory contention may
become an issue on large deployments.

There is no limit to the number of mongos routers you can
have in a deployment. However, as mongos routers
communicate frequently with your config servers, monitor config server
performance closely as you increase the number of routers. If you see
performance degradation, it may be beneficial to cap the number of
mongos routers in your deployment.