Ring topology support of MongoDB ReplicaSet and Sharding?
MongoDB (as at 3.0) only supports a single primary per replica set. Replica sets can have up to 50 members, with up to 7 voting members. The 2-node replica sets you have described should have a third member (either a data-bearing secondary node or a voting-only arbiter) to allow for failover. Replica sets require a strict majority of votes (n/2+1) in order to elect and maintain a primary, so a 2 node replica set requires both members to be healthy (see: Replica Set Elections).

Replication Topology

In terms of replication flow, the deployment of a replica set could be described as either:


A self-configuring tree topology, with the current primary as the root node. By default MongoDB allows replication chaining so secondary nodes can choose to sync from other secondaries based on ping time (for example, to mitigate bandwidth usage when multiple secondaries are in a remote data centre).
A self-configuring star (or hub-and-spoke) topology, if you disable replication chaining.


You can influence selection of the current primary by configuring member priorities for a replica set, but the general goal is to provision a set of peer nodes (with similar hardware resources such as CPU/RAM/disk) to allow any data-bearing secondary to be promoted to primary.

Sharded Cluster Query Topology

With a sharded cluster your application connects via the mongos routing service, which will direct queries &amp; commands to the appropriate shard(s) and aggregate results as required. The networking topology here might be described as a partial mesh, as each mongos connects to the 3 config servers and the current primary for each shard (and potentially secondaries, based on read preferences).

Note: Your approach with the use of distinct ports for different roles (replica set membership, config server, mongos) makes sense as a way to self-document the sort of service you are connecting to.