7.4 Site Architecture

Introduction:

There are several architectural approaches that materially reduce a site’s carbon footprint, and the underlying goal is the same throughout: reduce the amount of infrastructure needed to serve people. A traditional monolithic setup client requests hitting a web server, an app server and a database on every load carries far more compute and network overhead per request than a static site generation (SSG) or JAMstack approach, where content is created once in a headless CMS, built into static files, and served from a CDN with API/microservice calls only where genuinely needed. Migrating from on-prem or IaaS to PaaS, SaaS or cloud-native infrastructure can save a substantial share of the associated carbon; Microsoft’s own estimate for on-prem-to-PaaS migration is as high as 95%, though the real figure depends heavily on how well the original servers were utilised. Shared platform resources, decoupled or microservice architecture, auto-scaling, and turning off non-production environments outside working hours (7.2) all compound this further, and right-sizing resources with a combination of load testing and FinOps tooling (e.g. Nordcloud Klarity) helps avoid over-provisioning in the first place.

Resiliency patterns matter here too, and not just for uptime. The Circuit Breaker pattern, common in microservice architectures, is a genuinely sustainable design pattern: when a downstream service is slow or failing, naively retrying the call over and over exhausts network resources for no benefit. A circuit breaker instead trips to an “open” state after a failure threshold, fails fast without hammering the failing service, and periodically half-opens to test recovery avoiding wasted retries while the dependency is unhealthy.

If you’re running on Kubernetes, event-driven and carbon-aware tooling can reduce resource use further, KEDA’s autoscaler and CNCF projects like Kepler (see 6.11) bring carbon and utilisation data directly into scheduling and scaling decisions.