The storage animation goes through some of it but for the basics using something like an 80/20 rule for content popularity you can also apply that to data cost. Your most popular 20% of content needs to be as close to the client as possible and will probably be the most expensive for you to store (typically in 1 or many CDNs).

The next most popular 20% will probably be semi expensive but doesn't need to be as close. This can be a subset of CDNs (where it financially makes sense) or georeplicated s3 buckets.

The lower ~60% of your content probably doesn't get accessed very often (relative to "hot" content) and depending on your content and user demands can probably live in your own data centers or POP locations.

You'll want to make it as easy as possible to promote/demote content into these tiers. Content popularity happens seasonally and in different regions so keeping the APIs similar between tiers will help you a lot. S3 is a pretty good standard to build toward so you'll probably want something like that on-prem or in your k8s clusters (minio, swift, etc.). We're also talking about each movie having potentially thousands of assets to track (different encodings for video and audio and different DRM wrappers etc) and hundreds or thousands of terabytes for big catalogs. So using immutable object storage is going to save you a TON of time instead of sticking with POSIX based block or file storage.

During the file ingest (when your encoding it) you're probably going to be dealing with POSIX based files so the encoders can work on the file but you'll want as many systems after that dealing with object storage as soon as possible.