Yes!
No!
Maybe?
It all depends on what level of performance you need and how secure you want your data. If you need hundreds of reads per second, you'll want a storage system that can cache reads and that will cost you a nice sum of money and some of your own hardware. If all that you need is raw storage, then that simplifies things at least as far as architecture is concerned.
Data protection is likely important for you so take a double amount of storage into consideration to hold backups. You might want to look into deduplication with ZFS (BSD / Illumos) or SDFS (Linux). Replication, file versioning, security, SANs, BANs, bit level, block level, byte level...
Break it down into three levels:
Performance. Failure resilience. Backup resilience.
Start with performance. Figure out how many reads and writes you're dealing with. Move on to failure resilience. Figure out just how redundant you want to be. Geo redundant? Or is it acceptable to be confined to one datacenter? Do you want to have your content delivered to people in far reaches of the globe and have it be local to them? NExt is backup resilience. How much history do you want and how much versioning do you want. They all cost bytes.
TL;DR
There is no answer.
