MongoDB drivers use a Server Selection Algorithm to choose which replica set member to use (or, when connected to multiple mongos instances, which mongos instance to use). For a secondary read preference, the server selection process is as follows:

1. The driver assembles a list of eligible secondary members. maxStalenessSeconds and tag sets can further restrict the eligibility of the members, as documented here.
2. If the list of eligible members is not empty, the driver determines which eligible member is the “closest” (i.e. the member with the lowest average network round-trip-time) and calculates a latency window by adding the average round-trip-time of this “closest” server and the localThresholdMS. The driver uses this latency window to pare down the list of eligible members to those members that fall within this window.
3. From this list of eligible members that fall within the latency window, the driver randomly chooses an eligible member.

The above process is documented here. As can be seen here, this process does not use even-load-balancing as a criteria for selection of a secondary. In other words, the secondary selection process does not evenly distribute the incoming queries equally among available secondaries.

This is an enhancement request to add an intelligent "load-aware"  loadbalancing mechanism in the Server Selection Algorithm, which will evenly distribute the load among secondaries. Specifically, the mechanism will take into account the current load on each secondary and distribute the query-workload among them accordingly, so that each secondary has approximately the same amount of workload (and not necessarily the same number of read-requests).