A content and application platform must choose between many small points of presence and fewer larger regional sites. What trades off?

What many small locations give

Lower latency, because the user is physically closer, and better resilience to a single site failure since each serves less traffic.

What they cost: each location sees a fraction of total traffic, so its cache is colder and its hit ratio lower. More requests reach the origin, which increases origin load and can make the average response slower despite the lower network latency. Operationally, there are far more locations to deploy to, monitor and debug.

What fewer larger sites give

Higher cache hit ratio, because more traffic converges on the same cache, which for a large content catalogue is frequently the dominant factor in overall performance. Simpler operations, and more capacity per site to absorb a surge.

What they cost: higher network latency for distant users, and a larger blast radius per site failure.

The resolution most platforms reach

A tiered topology. Many small locations close to users, backed by a smaller number of larger caches that absorb their misses before anything reaches the origin. The edge tier gives latency; the shield tier gives hit ratio; the origin sees very little.

This also solves the thundering herd on origin: without a shield, a popular object expiring causes every edge location to fetch it simultaneously.

The variable that decides the emphasis

Catalogue size and request distribution. A small catalogue with heavy concentration caches well everywhere, so more locations is straightforwardly better. A very large catalogue with a long tail caches poorly at small locations, and the shield tier becomes essential rather than optional.