Static assets served slowly to overseas users
A media company stores 4 TB of images and short videos in an OSS bucket in the China (Hangzhou) region. Users are split roughly 70% mainland China and 30% Southeast Asia. Origin egress is high because a large share of requests miss cache, and Southeast Asian users report multi-second image loads. The bucket is private; the web app generates signed URLs with a 1-hour expiry. The team is considering enabling CDN and is unsure whether to use a single global distribution or separate configurations, and whether signed URLs will still work.
1. Design the CDN setup. Address acceleration scope, cache behavior, and whether the existing signed URLs remain valid.
Read the worked answer
Separate concerns:
Acceleration scope. A single distribution pointed at the Hangzhou origin will still make Southeast Asian users traverse back to China on cache misses. The team should use CDN acceleration that covers the overseas user base (an overseas/global acceleration configuration) and, ideally, place the origin or a replicated bucket closer to those users. Serving both populations from one China-only origin leaves the 30% segment with the same miss penalty.
Cache behavior. The high miss rate is the root cause of both cost and latency. They should set long TTLs on immutable media (content-addressed or versioned object keys), separate cache rules by file type, and enable range requests for video so players do not pull whole objects. Ignoring query strings or normalizing them prevents cache fragmentation.
Signed URLs. URL signing is validated at the CDN edge against the shared key; the signature and expiry travel with the request, so existing 1-hour signed URLs continue to work provided the CDN is configured for the same signing scheme and the key is synchronized. The team must confirm clock skew tolerance and that the origin still enforces its own authorization, so a leaked edge config does not expose the private bucket.
Finally, monitor cache hit ratio and origin egress after cutover; a rising hit ratio is the proof the design worked.
2. A stakeholder asks why they cannot simply make the bucket public to remove the signing complexity. How do you respond?
Read the worked answer
Making the bucket public trades a manageable complexity for an unbounded one. The media includes content the company may license or restrict by region or customer, and a public bucket means anyone with a guessed or leaked object URL can retrieve it indefinitely, with no expiry and no per-user revocation. Signed URLs give time-bounded, revocable access and let the app tie delivery to an authenticated session.
The right answer is to keep the bucket private and reduce the signing friction: centralize URL generation in one service, use longer TTLs only for non-sensitive assets, and rely on CDN caching so signing cost is paid once per object per edge rather than per user. If public delivery is genuinely desired for marketing assets, isolate those in a separate bucket with its own policy rather than loosening the main one.