The Megawatt Budget: Making Power a First-Class Constraint in UK System Design

For most of the last decade, power entered architecture discussions as a facilities line item: a number the estate team worried about, a redundant feed the IT organisation assumed would be there. In 2026 that assumption no longer holds. Connection queues run years deep in several UK regions, distribution network reinforcement is measured in substation upgrades rather than quarters, and planning conditions routinely cap the load a site may draw. The question "how many megawatts can we actually take, and for how long?" is now being asked in design authorities rather than plant rooms.

This is not a story about energy prices. It is a story about determinism. An estate that has never defined what it would switch off, in what order, and on whose authority, does not have a resilience posture — it has an assumption with a UPS attached.

Power belongs in the architecture document

Three figures should sit alongside recovery time and recovery point objectives in every solution design:

• Contracted capacity, in kilowatts, and the tolerance the provider will genuinely accept above it.
• Curtailment notice period — the interval between a request to reduce load and the moment it must be delivered.
• Shed cost per hour, expressed per service tier, not per data hall.

Where these are absent, the resilience case is incomplete. The design has quietly assumed infinite headroom, and the first constraint event will expose a decision that was never taken.

Step one: classify by what a workload can lose

Most estates classify by business criticality, which is too coarse for this purpose. What matters under constraint is tolerance: how long a transaction path can be slowed, paused or refused before the business consequence becomes unacceptable. A four-tier model works well in practice.

• Tier 0 — non-negotiable. Clinical decision support, payment authorisation write paths, safety and access control, security operations tooling. These run at full load until the last possible moment, and their power is reserved rather than allocated.
• Tier 1 — degrade, do not stop. Degradation within seconds, no data loss, reduced throughput or feature set. Customer-facing portals with queueing mechanisms belong here.
• Tier 2 — pause and resume. Queue-based processing that can be suspended without breaching an obligation, provided the backlog is bounded and the drain rate known.
• Tier 3 — deferrable. Reconciliation, analytics refresh, non-urgent batch, test environments. The first thing to go, and the thing most organisations have never counted.

Apply the classification per transaction path rather than per application. A payments service may be Tier 0 for authorisation and Tier 2 for management reporting; treating it as a single unit forces an all-or-nothing decision that will be taken badly under pressure.

It also helps to record a derived metric: watts per business transaction, per tier. It is a blunt instrument, but it converts facilities data into language a change board can act on.

Step two: design the ladder, not the failover

Continuity planning in most UK estates is organised around failover: site A to site B, cluster node to cluster node. Constraint events rarely respect that shape. What is needed is an ordered ladder of rungs, each with a trigger, an automated action, an accountable owner and a defined return path.

A typical ladder reads something like: suspend Tier 3 batch; reduce replica counts and non-essential telemetry sampling; drain Tier 2 queues to cold storage; move Tier 1 workloads to read-only or queue-only mode; consolidate remaining Tier 0 load onto the most efficient rows and shed the rest.

The trap is shared infrastructure. Identity providers, key management and hardware security modules, DNS, time services, jump hosts and log ingestion are the workloads you cannot shed — and they are frequently racked in the same row as the workloads you are about to consolidate. Ladder design starts by mapping those dependencies and confirming they survive each rung, including the rung where a row goes dark.

Step three: negotiate energy-aware service levels

Colocation and cloud contracts written before constraint became material tend to define availability and nothing else. Four additions are worth pursuing:

• Capacity bands with defined behaviour, so that an amber state — reduced load, reduced performance — is a contracted outcome rather than a breach.
• Notice periods and evidence obligations, including access to sub-metering data at row or rack granularity.
• Attribution of curtailment, clarifying who decides the order of shedding across tenants and what notice the provider must give.
• Service credits tied to notice failures, not to outages alone. A provider that curtails without warning has broken the operating model even if nothing went down.

Where demand-side flexibility arrangements are available, some estates can register for them, but the sums involved rarely justify designing for them alone; treat participation as a by-product of a ladder you needed anyway.

Step four: rehearse the constrained state

Failover tests are common. Constrained-state tests are not, and they are the ones that matter here. A useful exercise is deliberately unglamorous: agree a synthetic cap with facilities, then walk the ladder one rung at a time with the business in the room, timing each transition and recording what broke.

Three checks are worth building in every time. Confirm that monitoring and out-of-band management survive the rung — an estate that loses observability at the moment of constraint is flying blind precisely when it needs instruments. Confirm that runbooks are reachable without the systems they describe. And confirm that generator and cooling assumptions still hold, including whether emission limits or local air-quality conditions would prevent the testing regime you have scheduled.

Run the tabletop with the provider and, where the site is large enough to matter, with the network operator. The conversation is far cheaper before the constraint than during it.

Instrument the budget, then defend it

None of this survives contact with operations without measurement: per-rack and per-tenant metering, efficiency by hall, and a forward capacity forecast derived from growth rather than from the last invoice. Feed it into the configuration management database so that the same numbers inform placement decisions, change assessment and board reporting.

Auditors and regulators increasingly ask availability questions that cannot be answered from application monitoring alone. A power-aware architecture does not mean buying less capacity. It means knowing precisely what you would give up, in what order, on whose authority — and being able to prove it before the constraint arrives rather than after.