Persistent Address and Name Integration

The previous lesson set up the balancer and made every measurement by assuming one thing was fixed: the endpoint the client connects to. That endpoint is not fixed.

The fictional regional measurement network’s collectors change regularly. One is re-created during a maintenance window, one is replaced because it dropped out of the health check, one is added by the scaling group’s decision. On every change the machine itself is renewed — and the machine’s address belongs to the machine, it goes with the machine.

The places that hold the address, though, are not the machine. It is written separately in the client’s configuration file, in the monitoring system’s target list, in a security group’s source field, in third-party sensor owners’ allow list, and in the runbook. This lesson compares the address’s stability across three layouts and counts the persistent address’s own bill.

How a name record’s time-to-live works was measured earlier; this lesson does not repeat that measurement, it takes the time-to-live as an input.

• CN37. In the fictional measurement network, one period is 3,600 seconds and contains three instance changes: maintenance, unhealthiness, scaling. The request rate reaching the collector is a constant eight requests/second.
• CN38. The items holding the address are five: client configuration, monitoring target, security group source, the third party’s allow list, the runbook. Updating one item by hand fictionally takes 90 seconds, and items are updated in sequence.
• CN39. Moving the persistent address to a new instance takes 25 seconds, updating the name record takes 90 seconds; both are fictional. The name record’s time-to-live is 60 seconds and is an input — how this value was measured was done earlier, it is not re-measured here.
• CN40. Under the name-based layout, the old instance is kept up for the duration of the time-to-live; stale resolutions go to the old instance for this reason, not into a void.
• CN41. The persistent address quota is five per region. In this model an attached address is free and an idle one is one unit per hour; a month is 720 hours. The currency is fictional and its name is unit. Real providers today bill a public address whether it is attached or not; the model draws this line to isolate the extra cost of sitting idle.
• CN42. A released address returns to the pool and is given to another tenant in the second week. The weekly decay multiplier for stale requests is 0.55; the starting value and the multiplier are fictional.

// address/stability.mjs — model: what happens to the address when the instance changes. The
// fictional regional measurement network's collectors change three times. The name record's
// time-to-live was measured earlier; here it is an input, not re-measured.
const EVENT = [["maintenance", 600], ["unhealthiness", 1500], ["scaling", 2900]];
const RATE = 8;                // requests/second, constant
const ITEM = ["client configuration", "monitoring target", "security group source",
  "third party's allow list", "runbook"];
const ITEM_TIME = 90;          // fictional: one item updated by hand takes 90 seconds
const MOVE = 25;                // fictional: moving the persistent address to a new instance
const RECORD = 90;              // fictional: updating the name record
const TTL = 60;                 // input: the name record's time-to-live (measured earlier)
// [name, hand items, move, record, is TTL in play, where stale requests go]
const LAYOUT = [
  ["ephemeral address", ITEM.length, 0, 0, false, "old address / new owner"],
  ["persistent address", 0, MOVE, 0, false, "dropped"],
  ["name-based", 0, 0, RECORD, true, "old instance"],
  ["persistent address + name", 0, MOVE, 0, false, "dropped"],
];
const detect = (row) => row[1] * ITEM_TIME + row[2] + row[3] + (row[4] ? TTL : 0);
const E = [28, 12, 15, 18, 16, 25];
const print = (h) => h.map((d, i) => String(d)[i ? "padStart" : "padEnd"](E[i])).join("");
console.log(print(["layout", "hand items", "detect(s)", "requests/event",
  `in ${EVENT.length} events`, "where stale requests go"]));
for (const row of LAYOUT) {
  const secs = detect(row);
  console.log(print([row[0], row[1], secs, secs * RATE, secs * RATE * EVENT.length, row[5]]));
}

// --- The persistent address's own bill -------------------------------------------
// Collectors are written by address into third-party sensor owners' allow lists; that is
// why every instance needs its own persistent address. Quota and fee are fictional.
const QUOTA = 5, IDLE_FEE = 1, HOUR = 720;         // unit/hour, fictional monthly hours
const K = [16, 19, 19, 26, 21, 15];
const print2 = (h) => h.map((d, i) => String(d)[i ? "padStart" : "padEnd"](K[i])).join("");
console.log("\n" + print2(["peak instances", "average instances", "addresses needed",
  "instances outside quota", "idle address-hours", "monthly unit"]));
for (const peak of [3, 5, 7, 9]) {
  const average = Math.round(peak * 0.6);
  const assigned = Math.min(peak, QUOTA);
  const idle = Math.max(0, assigned - average);
  console.log(print2([peak, average, peak, Math.max(0, peak - QUOTA), idle * HOUR,
    idle * HOUR * IDLE_FEE]));
}

// --- Released address: the item that cannot be taken back ------------------------
// A released address returns to the pool. Because it was published, it keeps living in clients;
// the decay multiplier is fictional. The address is given to another tenant in the second week.
const START = 4200, DECAY = 0.55, WEEKS = 6, HANDOVER = 2;
const H = [8, 16, 22, 29];
const print3 = (h) => h.map((d, i) => String(d)[i ? "padStart" : "padEnd"](H[i])).join("");
console.log("\n" + print3(["week", "stale requests", "address owner", "gone to a stranger (total)"]));
let total = 0;
for (let w = 1; w <= WEEKS; w += 1) {
  const requests = Math.round(START * DECAY ** (w - 1));
  if (w >= HANDOVER) total += requests;
  console.log(print3([w, requests, w < HANDOVER ? "in pool" : "other tenant",
    w < HANDOVER ? 0 : total]));
}

layout                        hand items      detect(s)    requests/event     in 3 events  where stale requests go
ephemeral address                      5            450              3600           10800  old address / new owner
persistent address                     0             25               200             600                  dropped
name-based                             0            150              1200            3600             old instance
persistent address + name              0             25               200             600                  dropped

peak instances    average instances   addresses needed   instances outside quota   idle address-hours   monthly unit
3                                 2                  3                         0                  720            720
5                                 3                  5                         0                 1440           1440
7                                 4                  7                         2                  720            720
9                                 5                  9                         4                    0              0

week      stale requests         address owner   gone to a stranger (total)
1                   4200               in pool                            0
2                   2310          other tenant                         2310
3                   1271          other tenant                         3581
4                    699          other tenant                         4280
5                    384          other tenant                         4664
6                    211          other tenant                         4875

Item Count Sets the Time

The first table’s second column is this lesson’s core: the number of items updated by hand.

Under the ephemeral address layout this number is five. When the instance changes, the address changes too, and all five places holding the address must be updated by hand. The third column is this converted into time: five items, 90 seconds per item, 450 seconds total. This is how long it takes the client to notice the change.

Detection time is not a matter of skill, it is a direct multiple of the item count. If a sixth place started holding the address, the time would rise to 540 seconds. In a setup that does not know how many places write the address, detection time is not known either.

The fourth column converts this into requests: eight requests a second, 3,600 stale requests per event. Since there are three events in the period, the total is 10,800.

The second row places the persistent address. The address no longer belongs to the instance; it is a separate resource and is moved to the new instance when the instance changes. The number of items updated by hand drops from five to zero, because the value at the five places never changes. Detection time drops to the move operation itself, 25 seconds; stale requests fall to 200 per event, 600 for the period. From 10,800 to 600: eighteen times.

The third row measures name-based resolution. The address is ephemeral again, but the five items hold the name, not the address; the only thing updated on a change is the name record. Items by hand are zero, but the time is six times longer than the persistent address’s: 90 seconds of record update plus 60 seconds of time-to-live, 150 seconds total. The time-to-live is not measured here, it is added in.

The fourth row combines the two: the name points to the persistent address, only the address is moved when the instance changes, the record never changes. The time returns to the persistent address’s time, 25 seconds, and the time-to-live drops out of the equation. This is where name integration does not make the persistent address unnecessary — it works together with it instead.

Where the Stale Request Goes

The last column shows that the same numbers carry three very different meanings. The number of stale requests does not by itself carry a decision; where those requests land does.

Under the persistent address layouts, stale requests are dropped. At the moment of the move, the address is not attached to any interface; the client cannot connect, gets an error, and retries. Six hundred requests were lost, and the client knows it too.

Under the name-based layout, stale requests go to the old instance. This is not a side effect of the layout but the result of a decision: the old instance is kept up for the duration of the time-to-live. Three thousand six hundred requests get the correct answer. The cost does not show up in the table but can be counted: 60 seconds × three events = 180 instance-seconds during which two instances run at once. As the time-to-live grows, both the window and this extra capacity grow with it.

Under the ephemeral address layout, stale requests go to the old address, and that address is now free. Over the 450-second window, 3,600 requests carry measurement data and identifying information to an address whose ownership is unknown. Of the three layouts, the worst by count is also the worst in kind — but these two harms are independent of each other. Dropping stale requests to zero does not stop them from going to a stranger; for that, who owns the address must not change.

The Persistent Address’s Bill

The second table measures the persistent address on its own. Because collectors are written by address in third-party sensor owners’ allow lists, every instance needs its own persistent address.

The third column shows the need, the fourth the quota. There are five persistent addresses per region. When peak instances rise to seven, two instances cannot get a persistent address; at nine, four cannot. No matter how correctly these instances are configured, they cannot get past the third party’s allow list. The persistent address is a resource with a fixed count, attached to a group that scales: the group can grow, the address pool cannot.

The fifth and sixth columns count the cost in the opposite direction. The assigned addresses have to be held for the peak, but the group runs below peak on average. At peak five and average three, two addresses are attached to no instance for most of the month: 1,440 address-hours, 1,440 units a month. An unused address is billed; an attached one is not.

Read together, the two columns show the persistent address’s narrow band. Between peak three and five, the quota is enough, but the idle fee is at its highest point. At peak nine, the idle fee drops to zero — because all five addresses are always attached — but four instances are left without an address. The persistent address does not sit well with a group that scales too little or too much; it works in a narrow range in between.

A third cost sits not as a number in the table but in the first table’s second row: the move is an operation. The address does not move to the new instance on its own; a call is made, the address is detached from the old interface and attached to the new one. The 25-second window and the 600 dropped requests are that operation’s duration. The operation has another face too: the permission to take an address from one instance and attach it to another is a management endpoint, and whoever holds that permission can pull traffic to their own instance. While the persistent address fixes the value the client sees, it adds a switch that can change the machine behind that value.

The Released Address

The third table measures this lesson’s item that cannot be taken back.

When a persistent address is released, it returns to the pool. Release is a single operation and it is not reversible: there is no such thing as getting the same address back. The address is given to another tenant in the second week.

The problem is not that the address is gone. The problem is that the address was published. It was written in five places, and not all five of those places are under your control: the third party’s allow list and someone else’s runbook do not enter your update round. In the first week, 4,200 requests keep going to the released address. The decay continues but does not end: in the sixth week there are still 211 requests.

The second column’s total is the number that matters. From the second week through the sixth, 4,875 requests went to the address’s new owner. Inside those requests is measurement data, collector identity, and maybe an access token. The new owner did nothing; they rented the address and the traffic arrived.

Closing this surface is not retroactive. Once the address is released, the only thing that can be done is update the items, and the items under your control were already updated. The only decision that closes the surface is not releasing the address — that is, continuing to pay the idle address’s 1,440 units a month. The bill and the surface are two faces of the same decision.

The Decision That Stays

In this layer, the items the provider takes over: managing the address pool, redistributing a released address, the name resolution infrastructure itself, and the size of the quota.

Six items stay with the renter: which layout to use, how many items the address is written in, the time-to-live value, how long the old instance stays up, how many persistent addresses to assign, and whether to release the address. Five of them can change at any moment, and all five were measured with numbers in this lesson.

The sixth does not: a released address cannot be reclaimed. Like a balancer’s layer, this too is a decision that locks not at creation but at the moment of release — and release is the easiest of the items that stay with the renter to carry out: a single call, no warning, the monthly fee zeroed out. Its cost shows up months later, when you read it in the allow list of a tenant you never knew held the address.

The surfaces opened are also three, and all three were added in this lesson: the move permission (a switch that can pull traffic to a different instance), the permission to change the name record (the client redirects all traffic without noticing anything), and the requests a released address carries to a stranger. None of the three are visible inside the sentence “keep the address stable.”

Summary

• Under the ephemeral address layout, five items are updated by hand, and detection time is a direct multiple of that number: 450 seconds, 3,600 stale requests per event, 10,800 across three events.
• The persistent address dropped hand-updated items to zero, detection time to 25 seconds, and stale requests to 600 — eighteen times. Name-based resolution sits in between: 150 seconds, 3,600 requests, because the record update has the time-to-live added on top.
• The number of stale requests does not by itself carry a decision: under the persistent address they are dropped, under the name-based layout they go to the old instance kept up for the time-to-live (180 extra instance-seconds of capacity), under the ephemeral address they go to an address that has already been freed.
• The persistent address works in a narrow band: at peak nine instances, four are left outside the quota; at peak five, two addresses sit idle and write 1,440 units a month. In the model an attached address is free, an idle one is billed.
• A released address cannot be reclaimed, and because it was published it does not die: from the second week through the sixth, 4,875 requests went to the address’s new owner. The only decision that closes the surface is not releasing the address — that is, continuing to pay the idle fee.

Next Step

The last two lessons set up the endpoint the request finds: the balancer decided which instance to go to, the address and the name kept that endpoint stable. Every request reaching the measurement network’s dashboard now arrives at the correct machine.

Every request still arrives at that machine. The regional map, the counter list, and the asset files travel the same path for a client far away too, and an egress fee is charged for every byte leaving the origin server. The same map leaves the same region thousands of times a day.

A portion of these responses can be kept much closer to the client. The edge cache’s mechanics were measured earlier; the next lesson treats the edge as a rented service and counts three things: how much the hit rate lowers requests reaching the origin, at which hit rate the total bill turns over when edge egress and origin egress are priced separately, and how many requests and seconds an invalidation costs. The decisions the edge takes over are also counted item by item: how many of the cache key, freshness, and compression decisions stay with the renter.