The Grid Is a Network: Lessons from Running the Internet

The power grid is the largest machine ever built. Over 12,500 utility-scale power plants feed more than 200,000 miles of high-voltage transmission lines, stepping power down through a web of substations and distribution feeders to reach every outlet in the country. The National Academy of Engineering called it the greatest engineering achievement of the 20th century. And we still run it on a design philosophy from 1886.

That year, William Stanley Jr. built the first AC power system in Great Barrington, Massachusetts. The architecture was straightforward: one central generating plant, high-voltage transmission lines, step-down transformers, one-way power flow, centralized control. It worked. It worked so well that 140 years later, the fundamental topology has barely changed. Big plants push electrons down long wires to passive consumers at the edges.

But the edges are no longer passive. Rooftop solar, battery storage, electric vehicles, distributed generation. Power now flows in both directions. The grid is becoming something its designers never intended: a network.

If that sounds familiar, it should. The computing world went through the same transition decades ago.

Two Networks, One Architecture

In the 1960s, computing looked a lot like the power grid. Centralized mainframes. Dumb terminals. One-way information flow from the core to the edge. IBM controlled the architecture, and every computation passed through a single, massive, expensive machine.

Then came ARPANET, TCP/IP, and eventually the internet. Computing decentralized. Intelligence moved to the edges. Any node could be both a producer and a consumer of data. The network became distributed, meshed, and self-healing. Routing protocols like BGP allowed traffic to find alternate paths when links failed. Content delivery networks pushed data closer to users. Load balancers distributed demand across multiple servers.

The power grid is being forced through an identical transition. Rooftop solar turns consumers into producers. Battery storage creates local buffers. Electric vehicles add massive, mobile loads that appear and disappear unpredictably. DERs (distributed energy resources) push generation to the edge, just as CDNs pushed content to the edge of the internet.

The architectural parallels are not metaphorical. They are structural.

Internet Pattern	Grid Equivalent	Function
BGP Auto-Rerouting	FLISR	Detect failure, reroute around it automatically
Load Balancer	Dispatch Center	Distribute demand across available resources
CDN Edge Node	DER	Serve from the edge, reduce backbone load
Software Circuit Breaker	Protective Relay	Fail fast, prevent cascading failures
Retry with Backoff	Auto-Recloser	Handle transient faults, escalate persistent ones
DDoS Protection	Fault Current Limiter	Absorb surge, protect downstream infrastructure
Anycast DNS	Distributed Generation	Route requests to nearest available source

Consider FLISR, fault location, isolation, and service restoration. When a fault occurs on a distribution feeder, FLISR detects it, isolates the faulted section by opening switches, and reroutes power from adjacent feeders to restore service to unaffected customers. This is BGP convergence. When a link fails on the internet, BGP withdraws the route, neighboring routers recalculate paths, and traffic flows around the failure. Same function. Same architecture. Different physics.

Ameren Missouri deployed smart switching and FLISR automation across its distribution system through its Smart Energy Plan and prevented 160,000 customer outages in 2025 alone. That is not incremental improvement. That is the kind of step-function reliability gain the internet achieved when it moved from static routing to dynamic protocols.

Where the Analogy Breaks

Before this becomes a TED talk about how "the grid is just like the internet," we need to confront the critical difference.

On the internet, packets are routed explicitly. BGP configurations, routing tables, forwarding rules. Software determines where data goes. An engineer can write a policy that says "traffic from AS 64500 should prefer the path through AS 64501," and the network obeys.

Power does not work that way. Electrons follow Kirchhoff's laws. Current divides inversely proportional to impedance. You cannot tell a megawatt to take the northern transmission path instead of the southern one. Physics determines the path, not configuration. When a large solar farm injects power at a distribution node, that power flows according to the impedances of every connected line. No routing table. No policy engine. Just physics.

This makes grids fundamentally harder to control than data networks. The internet's routing layer is a software abstraction over physical links. The grid's routing layer is the physical links. When a new DER connects, it changes the power flow patterns across the entire local network. When a large industrial load cycles on, impedance relationships shift. The grid's "routing" recalculates itself continuously, governed by Maxwell's equations rather than configuration files.

This constraint does not invalidate the architectural comparison. It sharpens it. The internet solved distributed reliability through explicit control. The grid must solve it despite lacking that same control. The reliability challenge is identical. The solution space is more constrained. That makes the engineering harder, not less important.

And it makes the discipline of systematic reliability measurement even more critical. When you cannot explicitly control routing, you need better observability, tighter feedback loops, and faster automated responses. Which is exactly what SRE provides.

The Internet Already Solved This

Google runs services at 99.999% availability. Five nines. That translates to roughly 5 minutes of downtime per year across billions of users. The U.S. power grid, in a typical year excluding major events, averages about 99.98% availability (approximately 118 minutes per customer per year, per recent EIA data). Include major storms and the number drops further. That gap, from 99.98% in a good year to 99.999%, represents the difference between roughly 2 hours of outages per customer and 5 minutes.

The question is not whether 99.999% is achievable for the grid. Different physics, different failure modes, different economics. The question is how Google and its peers achieved reliability improvements of that magnitude, and which of those methods transfer.

Google's Site Reliability Engineering practice, which we introduced in Part 1, is built on four pillars:

1. Explicit SLOs. Every service has a quantified reliability target. Not "high availability." A number. 99.95% for this API. 99.99% for that storage system. The target drives every engineering decision.
2. Error budgets. The gap between the SLO and 100% is a budget to spend on change. If your SLO is 99.95%, you have 0.05% of time available for failures caused by deployments, experiments, and upgrades. When the budget is exhausted, you freeze changes and focus on reliability.
3. Continuous monitoring with automated response. Not daily reports. Not monthly summaries. Real-time telemetry feeding automated systems that detect anomalies and trigger remediation in seconds.
4. Chaos engineering. Deliberately injecting failures to verify that systems degrade gracefully. Netflix's Chaos Monkey randomly terminates production servers to ensure the system survives individual node failures.

Now consider how most utilities measure reliability. SAIDI and SAIFI, reported annually to state regulators. Some utilities calculate monthly. A few track weekly. But the feedback loop between a reliability event and an engineering response is measured in weeks or months, not seconds.

Imagine Google checking its server uptime once a year. Compiling an annual report. Submitting it to a regulatory body. Waiting for approval to make changes. That is, functionally, how utility reliability management works today. It is not that utilities are negligent. It is that the measurement and feedback systems were designed for a grid that changed slowly. A grid with one-way power flow, predictable load curves, and centralized generation that dispatchers could see and control.

That grid is disappearing. The new grid, with bidirectional flows, variable renewable generation, and millions of edge devices, needs a reliability framework built for continuous measurement and rapid response.

Reliability Patterns That Transfer

Software reliability engineering has produced a set of well-tested design patterns for building resilient distributed systems. Several of these map directly to existing grid equipment and practices. The value is not in the hardware. Utilities already have much of it deployed. The value is in the operational framework that connects these components into a coherent reliability strategy.

Software Pattern	Grid Application	How It Works
Circuit Breaker	Protective Relay	Detect abnormal conditions and disconnect fast, preventing a local fault from cascading into a system-wide failure. In software, a circuit breaker stops calling a failing service. On the grid, a protective relay trips a breaker to isolate a faulted line.
Bulkhead	Feeder Sectionalizing	Partition the system so that a failure in one compartment cannot flood into others. Software bulkheads isolate thread pools or service instances. Grid sectionalizers divide feeders into independently isolable segments.
Retry with Backoff	Auto-Recloser	Most faults are transient. A tree branch touches a line, an animal crosses a bushing, lightning induces a momentary flashover. Reclosers handle roughly 80% of distribution faults by opening briefly, allowing the fault to clear, then re-energizing. Each retry waits longer than the last. This is exponential backoff, implemented in steel and oil decades before software engineers gave it a name.
Timeout	Relay Coordination	Set time limits on operations so the system does not wait indefinitely. Relay coordination curves ensure that the relay closest to a fault trips first, with upstream relays waiting progressively longer before acting as backup.
Rate Limiting	Generation Ramping	Control the rate of change to prevent system instability. Software rate limiters cap requests per second. Ramp rate limits on generators prevent frequency excursions from sudden output changes.

The recloser example is worth pausing on. Auto-reclosers have been deployed on distribution systems for decades. They are among the most effective reliability devices ever invented, handling roughly 80% of faults without requiring a crew dispatch. They implement retry-with-backoff. They are also circuit breakers in the software sense, opening to prevent downstream cascade when a fault persists.

But most utilities do not monitor recloser operations in real time. They do not track the ratio of successful recloses to lockouts. They do not use recloser data to identify feeders with deteriorating vegetation clearance or aging equipment. The device is deployed. The operational framework around it is thin.

SRE changes that. In an SRE model, every recloser operation is telemetry. A rising lockout rate on a feeder triggers an investigation before customers experience sustained outages. The recloser becomes a sensor, not just a switch. The same device, the same hardware, produces dramatically better reliability outcomes when embedded in a continuous measurement and response framework.

From Pipeline to Network

The power grid was designed as a pipeline. Energy flows from source to sink, one direction, centrally controlled. That model worked for a century. It is breaking now, not because it was poorly designed, but because the system it was designed for no longer exists.

Rooftop solar reverses power flow. Battery storage creates time-shifting buffers that decouple generation from load. Electric vehicles add enormous, mobile, unpredictable demand. Distributed generation turns the edges of the network into both producers and consumers. The grid is becoming what the internet became in the 1990s: a multi-directional, edge-heavy, distributed network where intelligence and capability are spread across millions of nodes.

The internet's reliability engineering discipline, SRE, emerged because the old ways of managing centralized systems could not handle distributed complexity. Annual capacity planning could not keep pace with exponential traffic growth. Manual incident response could not match the speed of cascading failures across interconnected services. Static architectures could not accommodate the constant change required to serve a global user base.

Utilities face every one of these challenges today. Load growth from electrification is accelerating. DER interconnections are changing grid behavior faster than annual planning cycles can model. Storm intensity and frequency are increasing, driving more complex cascading failure scenarios. The tools and frameworks that addressed these challenges for the internet are directly applicable.

The grid was the greatest engineering achievement of the 20th century. Making it resilient, adaptive, and self-healing will be one of the defining challenges of the 21st. That work starts with a shift in mental model. The grid is no longer a pipeline. It is a network. And networks demand a different kind of reliability engineering.

Traditional grid planning uses N-1 and N-2 contingency analysis, designing the system to survive the loss of one or two critical components. That approach was adequate for a centralized, predictable grid. In Part 3, we examine why N-1/N-2 planning cannot keep up with a networked system where the number of possible failure combinations grows exponentially with each new DER, storage system, and bidirectional interconnection.