[fafner]

Unfortunately some customer changes will need to go out quickly and globally for a CDN. Going much slower might not be a good option.

Canarying should detect this. Not clear if they do this or the canary failed to report this.

Sharding by customers could help reduce blast radius. But maybe not by much of this was a very big customer.

[thethethethe]

> Unfortunately some customer changes will need to go out quickly and globally for a CDN

Why is this the case? I don't have too much knowledge of CDN architecture so I am curious

[rblatz]

Pushing out new versions of your site. You can’t have the new assets on half the nodes that are serving your site otherwise your site goes down while things slowly propagate.

[notyourday]

> Why is this the case? I don't have too much knowledge of CDN architecture so I am curious

Fastly is not really a regular CDN. It is a fully programmable edge cache with cache control algorithms decided and controlled by the customer running at the edges. You can think of Fastly configuration as a part of your code base where it is for you to decide if you want to perform the action on the edge on a per-request basis rather than on the origin per cached request basis.

That in turn means that if you do deploy to your API/web 50 times a day, you would are likely to deploy your Fastly configurations about the same number of times

[aliasEli]

Sharding would also introduce additional complexity into the system, which is also risky.