MatrixEdge.
1 Matrix Systems Innovations Ltd, Cardiff CF10
Abstract
MatrixEdge is an adaptive edge layer comprising a content cache, a routing layer and a TLS terminator. We describe the auto-tune v2 reinforcement loop that decides per-route, per-hour, per-region TTLs from observed traffic and downstream origin cost under an operator-declared constraint set. We give the published calibration discipline, the deployment shape, and the explicit list of decisions the system declines to make on the operator's behalf.
What MatrixEdge actually does at the edge.
A great deal of CDN documentation describes what a CDN is, in marketing terms, before saying what the specific CDN does. We will skip the first sentence. MatrixEdge does four things at the edge, in this order: (1) it terminates TLS against the customer's certificate; (2) it matches the request against the route table and, where the route is cacheable, against the cache key; (3) on miss, it routes to origin under the routing policy — the operator's, not ours; (4) on every response it writes a decision record into the WebMatrix data model so that the observability and policy surfaces can read what the edge actually did.
What changes with auto-tune v2 is what fills the TTL slot in step (2). Until v2, the TTL was the operator's static guess. With v2, the TTL is a per-route, per-hour, per-region decision made by a reinforcement loop that reads the data model's D column and writes back into it. The loop optimises for a three-dimensional target — origin cost, p99 tail latency, hit ratio — under a constraint set the operator writes once. The constraint set, not the target, is what makes the loop behave.
The numbers we publish; the numbers we do not.
We publish the calibration plots for the auto-tune loop, per route class, refreshed weekly. We publish the rolling 28-day p99 distribution per region, with the suspension events documented inline. We publish the loop's "decision deltas" — every place the loop changed a TTL by more than 50 % from the previous hour, with the reason recorded in plain English on the decision record.
We do not publish customer cache keys, customer traffic patterns, customer hit ratios. We do not publish the origin cost your auto-tune loop is optimising against — the cost function is yours. We do not put aggregate customer numbers into our marketing copy. The dashboard is the document.
| Quantity | What we publish | What we do not publish |
|---|---|---|
| Calibration | Per-route-class plots, weekly | Per-customer plots |
| p99 latency | Per-region, rolling 28 days | Per-customer per-route |
| Decision deltas | ≥ 50 % TTL changes, reason field | The cache key itself |
| Suspension events | Date, lane class, duration, root cause | Customer name, traffic shape |
| Cost function | The constraint shape (α, β, γ) | The customer's α, β, γ values |
Table 1 The publication discipline. The principle: publish the methodology and the calibration; never publish the customer.
How MatrixEdge is deployed.
The deployable shape is conventional. Anycast PoPs, BGP-announced from fourteen sites across three regions. The customer's certificate is held in the customer's HSM-backed key store and presented at termination; we do not hold private keys. The routing policy is the customer's, expressed as data and signed against the release tag.
What is not conventional is the kernel-isolation discipline. Multi-tenancy at MatrixEdge is enforced at the cgroup and the network namespace, not at the SLA. A noisy neighbour on a shared PoP cannot — measurably — degrade another tenant's p99 tail. We test this every release with a deliberate noise-generation customer (us, against ourselves) and we publish the result.
Calibration discipline.
The auto-tune loop is calibrated against a rolling 28-day window per region. When a region falls outside the calibration window — a new PoP, a major traffic shift, a known incident — the loop is suspended on that region, the operator is informed by the same data-model channel, and the TTL on suspended routes reverts to the operator's declared static value until the window closes. We have had two such suspensions in the life of v2; both are in the public calibration log.
An engineering call against your origin.
The most useful conversation about MatrixEdge is held against your traffic, your cache keys (which we never look at) and your declared cost function. Forty-five minutes; written technical note same day; no obligation to continue. The note tells you what the auto-tune loop would propose, the calibration window it would need, and the routes for which we would not recommend turning the loop on at all.