Okay, that's a conversation that really ought to be spoken over a lot of beer. You are basically asking "what are the considerations when (re)architecting an entire splunk ecology?" Without knowing more about your use case(s), I could wear down my fingers expounding on the internet without providing you the insights you most need.
Separating data by index and sourcetype -- segregating data with regard to how that data is going to be used -- is one key to efficiency of access, as long as you don't go too far. (Pretty much like normalization in relational databases. You normalize the overall design, then denormalize selectively to achieve maximum workability for your real-world applications.)
When considering what indexes to create, consider your users and their various roles, as well as the sensitivity of the particular classes of data involved. Consider frequency of access to each type of data, and consider granularity...whether the data will be generally needed at the detail level, or whether (and to what degree) aggregates in summary indexes would adequately meet most needs.
The metadata overwrite operation (transforms) will happen on the Heavy forwarder, so make sure you've sufficient number of heavy forwarders (at least one per indexer you have) with decent h/w configurations. The reference h/w size will depend upon the data load you'll per indexer. This may help.