Building an Enterprise Anycast CDN at the Network Edge

This series is a theory — my theory. It is not presented as a standard, a prescription, or a finished product, but as a deliberate exploration of an idea that emerges from operating large networks over time. Some parts are well‑understood practices; others are hypotheses tested through reasoning, experience, and constraint. Like any good theory, it is meant to be examined, challenged, adapted, and occasionally rejected. What follows is an attempt to think clearly and honestly about what might be possible, not to declare what must be done.

Section 8 — Who This Is For, and What It Trades Away

By this point, the shape of the system should be clear. What matters now is not whether it works — but whether it is appropriate.

This architecture is opinionated. It makes deliberate tradeoffs. It fits some organizations extremely well, and others not at all.

Who This Architecture Is For

This approach is well-suited to organizations that:

• Operate a large number of Internet-connected sites
• Already run BGP and understand its failure modes
• Have predictable regional customer presence
• Possess private transport that can complement, but not replace, the Internet
• Value determinism and fault isolation over abstraction

For these organizations, the edge is not a black box — it is an asset.

Who It Is Not For

This architecture is likely a poor fit for organizations that:

• Rely entirely on managed edge platforms
• Do not control their routing policy
• Expect the network to infer application intent
• Prefer centralized decision-making
• Cannot tolerate operational responsibility at the edge

There is nothing wrong with these positions. They simply imply different constraints.

The Tradeoffs, Made Explicit

Every architectural choice carries cost.

This design trades:

• Abstraction for control
• Convenience for clarity
• Automatic optimization for explicit signaling

In return, it gains:

• Predictable failure behavior
• Bounded blast radius
• Transparency under stress
• Independence from external control planes

These are not universally desirable properties. They are situationally valuable ones.

On Complexity and Simplicity

At first glance, this system may appear complex. It involves multiple routing domains, explicit trust boundaries, and careful ordering.

In practice, its complexity is structural rather than incidental.

Each component:

• Has a single responsibility
• Operates within tight limits
• Fails in predictable ways

The system avoids cleverness not by being small, but by being disciplined.

A Theory, Revisited

As stated at the beginning, this series presents a theory.

It is not a claim that this is the best way to build an enterprise edge — only that it is a coherent way, given certain starting conditions and priorities.

Some organizations may adopt pieces of it. Others may reject it entirely.

Both outcomes are valid.

The value lies in making the tradeoffs explicit, and in demonstrating that large-scale edge systems can be built with restraint rather than accumulation.

Closing Thought

Networks age. Assumptions harden. Convenience becomes dependency.

Occasionally, it is worth stepping back and asking not what is easiest to consume — but what is possible to operate.

This series is one such attempt.