Content Delivery Network

Outcome: Design or review Content Delivery Network for this system while keeping data correct, secure, and easy to operate. User context: A global docs site caches fingerprinted, unchanging JavaScript for one year. HTML uses a five-minute shared max-age with `stale-while-revalidate` and varies only by accepted encoding. After a correction it purges one article's surrogate key, while signed-in account pages skip shared caching. Technical concept or control: Content Delivery Network. Why it fits: Use a CDN to serve people from many regions. Plan cache keys, freshness, purge, privacy, origin protection, and failure behavior. Do not use it when: Do not share-cache personal or permission-sensitive replies. Do not vary on unlimited inputs or promise an instant purge without measuring it. Engineering requirements: Define inputs, outputs, contracts, and rules that must always hold. Set authorization and input checks. Define failures, timeouts, retries, one-time effects, data moves, and compatibility limits. Operations: Add useful signals and logs that hide sensitive data. Set capacity limits and write an operator guide. Test recovery and rollback. Acceptance criteria: Contract and failure-path tests pass. Data and authorization rules still hold during retries and partial failures. Check performance limits, monitoring, recovery, and rollback. Evidence and limits (evidence boundary): No single official standard controls the whole term. Its meaning may change across teams, platforms, or frameworks. Unknowns to confirm: Where the code runs, data stores, traffic shape, consistency needs, and the security boundary. Also confirm the compatibility period, service goals, and rollback limits.