If your common queries aren’t using the shard key they will be scatter-gather (directed to all shards in the cluster). This won’t be ideal for performance if you have hundreds of shards to query. If your goal is to efficiently scale out, it would be better to have range-based shard keys that support your common queries and allow for targeted queries. For more information see Read Operations to Sharded Clusters.
An important consideration with capacity planning is your working set of actively used data and indexes. If your use case has a large amount of historical data that is infrequently accessed, the desired ratio of storage to RAM will be different than working with the same data set in memory. Scalability has several dimensions (cluster scale, performance scale, and data scale) which will affect your deployment decisions. For some examples of different scaling scenarios, see: MongoDB at Scale.
Depending on your use case, you may also want to consider zone sharding with tiered resources for varying SLA or SLO.
I’d recommend getting Professional Advice to plan a deployment of this size. There are many considerations, and an experienced consultant can provide better advice with a more holistic understanding of your requirements. Some decisions affecting scalability (such as shard key selection) are more difficult to course correct once you have a significant amount of production data.