Web Pattern: Use Content Delivery Network

[chauhannishh]

Create a new web pattern where one should use CDN

Title

Title of the pattern

Version

Designation of iteration on the pattern. This will initially be assigned by the patterns working group

Submitted By

The name of the person(s) submitting the pattern

Published Date

The date this version of the pattern is published. This will be provided by the patterns working group upon approval

Intent

Subtitle describing what this pattern is expected to do

Tags

Pre-defined list of tags which might apply to the pattern (e.g. Cloud, Web)

---
tags:
 - cloud
 - web
---

Problem

What is the problem this pattern is solving

Solution

How will this patter solve the problem

SCI Impact

How will this pattern affect an SCI score of an application and why

`SCI = (E * I) + M per R`

Assumptions

What are the assumptions being made

Pros & Cons

Discussion section for pros and cons of this pattern

- **PRO**:
- **CON**:

[russelltrow]

Thanks for submitting this, @chauhannishh . The core idea is solid — CDNs are a legitimate green software decision — and there's good content here. I've got some structured feedback to help strengthen the pattern before we move forward.

The Big Picture

Your pattern relates closely to an existing pattern called "Cache static data" Both address the same core problem: reducing network transmission distance to lower energy (E) and embodied carbon (M). The existing pattern covers local caching; yours extends that principle to global distribution. These are complementary approaches, but we want to make sure readers understand when to use each one and how they connect.

Critical Issues

1. Embodied Carbon — Key opportunity to strengthen the pattern

This is the most important aspect. The existing "Cache static data" pattern makes a valuable point that we'd like to see reflected in yours: "If any external cache infrastructure is leveraged, then SCI score may not reduce considerably as we have to account for the E and M values of the external infrastructure."

CDNs introduce embodied carbon costs through distributed servers, edge nodes, and networking equipment — this adds M to the equation. Your pattern would be significantly stronger if it:

• Addresses this trade-off directly
• Explains when that trade-off is justified (global audiences are the main use case)
• Compares E savings vs. M costs across the system lifecycle
• Demonstrates scenarios where CDN adoption delivers clear benefits versus where it may not

This kind of analytical honesty distinguishes rigorous green software guidance from promotional content.

2. Cost Impact — Important to include

CDNs introduce real operational costs that readers should understand:

• Licensing fees (per GB, per request, or monthly)
• Ongoing provider management
• Potential offset by reduced origin infrastructure costs

Adding a Cost Impact section would help clarify:

• Which cost lines are affected and how
• Whether the pattern typically increases or decreases total spend
• How the cost/benefit picture varies by use case

3. Title — Align with our naming conventions

"Content Delivery Network (CDN)" reads as a definition rather than a pattern title. GSF patterns follow an "[Action] [Resource]" format. Consider one of these:

• "Cache static assets on a Content Delivery Network"
• "Deploy a globally distributed Content Delivery Network"
• "Use a CDN to reduce data transmission distance"

Choose the option that best matches your intended scope.

4. Solution — Focus and scope

The solution currently addresses several distinct decisions:

• CDN adoption (infrastructure choice)
• Asset caching strategy (architectural choice)
• Vendor green commitment (procurement choice)
• Compression optimization (covered separately in "Compress transmitted data")

I'd recommend narrowing the focus to the core question: what to cache on a CDN and why. This will make the pattern more focused and useful.

5. SCI Impact — Technical adjustments needed

A few refinements to this section:

• Order: follow the standard E → I → M → R sequence. Currently it's E → R → I.
• Renewable energy claims: statements like "Cloudflare, Akamai, and AWS CloudFront operate on renewable energy" need verification. AWS CloudFront, for instance, doesn't guarantee renewable energy globally. Either cite specific provider commitments with sources, or adjust the language to be more cautious.
• M (embodied carbon): this is missing and deserves its own analysis in the SCI Impact section.
• R (functional unit): clarify what the denominator is — per user? Per request? Per GB?

What We'd Suggest: Reframe as an "Upgrade Path"

Consider presenting CDN as an informed upgrade to local caching rather than a standalone pattern:

While local caching (see "Cache static data" pattern) reduces transmission distance and embodied carbon through efficient hardware use, local caching only benefits users geographically close to the server. For globally distributed audiences, a Content Delivery Network extends this principle across continents, accepting increased embodied carbon from distributed infrastructure in exchange for energy savings across the entire user base. Only adopt CDN if: (1) your audience is truly global, and (2) energy savings from reduced transmission distance outweigh the embodied carbon of additional infrastructure.

This framing positions CDN as a deliberate, informed choice with clear trade-offs, demonstrates alignment with the existing "Cache static data" pattern, and shows you've thought through the embodied carbon question.

Next Steps

Our team can help with pattern refinement if you'd like to revise. I'd suggest prioritising these items:

1. Rebuild SCI Impact in E → I → M → R order, with honest treatment of embodied carbon
2. Add Cost Impact section
3. Reframe as an upgrade path to "Cache static data"
4. Revise title to "[Action] [Resource]" format
5. Tighten Solution scope to focus on what to cache and why

The foundation is there — it needs deeper analysis on trade-offs and clarity about when CDN adoption makes sense.

Let me know if this direction works for you. The team are happy to discuss further.

Note: This initial review was generated using a Claude AI skill for pattern evaluation. The recommendations reflect our review standards, but a team member will follow up with any further feedback.