Request Routing (The Dark Art of the CDN)
I covered the technical basics of request routing in Chapter 2, Section 2.5.3. However, there are some considerations that are relevant to the publisher that are worth adding.
Once you publish a URL to an item of content, that URL (where you are using a CDN) is a key data item that ties your users to the content, and their ability to find the content in your CDN. If those links expire (which may be desired in some models), the content becomes unavailable.
Controlling this link is paramount to the survival of your business. If the request router cannot connect users to their content, then no matter how good the CDN is, the content cannot be accessed.
Publisher strategies may include having your own top-level request router, which in turn provides access to the URLs to the request Rrouters of various CDNs, in effect giving you multi-vendor redundancy in the event of an entire vendor going out of service. This is key for high-availability premium services.
It may be that you decide to use a CDN brokerage (also mentioned in Section 2.5.4 above), which in effect measures your various CDN options and chooses the best balance between QoS and cost for you. Again, the brokerage - which is essentially an intelligent request router - could potentially fail, so you may want to have redundancy of multiple CDN brokerages. Obviously that could endlessly cascade, and sometimes the complexity itself can cause more issues than it solves.
In practical terms the only way to get this right is to evolve it in a real-world environment. But bear in mind at all times that if the user's request cannot be routed, then no matter how good the CDN, the user won't get any service!