Detailed Component Design

Let's discuss about the Metadata Control Plane:

We need to have multiple server available for read, but maybe we can have much less write server, as the read/write ratio is probably 1000:1, or even higher. Also, for write operation, we don't even need a strong consistency, as long as it is eventually persisted, so we really just need to scale for read as that's our main service for.
For the Database, a SQL like storage is for video title, uploader, and like/repost etc... those are quite structural data, we can take SQL relational Database, but considering what we mentioned for the read heavy service, probably cache is not sufficient, we may still suffer from a huge amount of read operation frequently, so my idea is to do Database sharding in this case, there could be many strategies but I am not going to dive too deep here, one simple way is sharding by some key as our data is structural. Perhaps we can continue polishing the design in practice like using some other database type (cassandra etc..)

For the Data Plane:

Now main issue, what happen if CDN is missing for cache. Well before we talk about this, there could be many strategy to cache, like some hot data should definitely being cached frequently, we will need to monitor those "superstar" video, that's optimization for celebrity. With that strategy, if we still have a missing cache, we can also have multiple data center across the world, so when a missing cache really happens, CDN can at least load it from the closest data center for best latency performance, and sometimes we will have to accept there is chance that we will have to load data from the HQ data center.
As the interviewer asked, the transcode pipeline, so we have multiple pipeline for different resolution, and some high-resolution pipelines may need more resources and that's what my Trancoding Distributor for.
For the transcode pipeline broken-resume issue, I guess this can be handled using the same strategy with the original uploading, which is cut the data into chunks and use some queue to handle the upload. When we met an issue and have to resume, we just need to check the last completed chunk, and started from that again, and it may not even need to be chunk-in-order, we can scan chunks by chunks for data integrity and only download the missing parts.