Skip to content

CONCEPT Cited by 1 source

Hardcoded literal address antipattern

The hardcoded literal address antipattern is the practice of writing literal IP addresses (or raw endpoint identifiers) into configuration where a name — DNS, a service registry, a well-known alias — is the intended integration point. When the underlying identifier changes (migration, renumbering, certificate rotation, etc.), the hardcoded configuration breaks.

The Fly Postgres instance

The canonical wiki example, from Making Machines Move:

Problem: the embedded routing information in a 6PN address refers in part to specific worker servers.

That's fine, right? They're IPv6 addresses. Nobody uses literal IPv6 addresses. Nobody uses IP addresses at all; they use the DNS. When you migrate a host, just give it a new 6PN address, and update the DNS.

Friends, somebody did use literal IPv6 addresses. It was us. In the configurations for Fly Postgres clusters.

The DNS layer was the intended contract; the Fly Postgres- cluster config bypassed it. Migration — which changes a Machine's 6PN address — breaks clusters whose configs point to the old address directly.

Fly's recovery

The recovery was two-phase:

  1. Ship a compatibility feature in guest — init gained "network address mappings to keep old 6PN addresses reachable." init maintains a mapping from the old address to the new one and intercepts traffic addressed to the old one, so the Postgres cluster keeps working without immediate config changes.
  2. Fleet-wide config rewrite — "We burned several weeks doing the direct configuration fix fleet-wide." The in-guest address mapping is a bridge, not a replacement; it lets Fly do the config fix without customer-visible downtime.

Canonical instance of patterns/feature-gate-pre-migration-network-rewrite.

Why it happens

Hardcoded addresses show up because:

  • Debugging bypass. The engineer wants a direct address for a one-off; the one-off escapes into production config.
  • Bootstrap dependency. DNS isn't available yet at cluster- form time; the cluster config has to use addresses.
  • Operational control. Some clustering protocols (Postgres streaming replication, Redis Sentinel, etcd bootstrap) want concrete addresses for consensus or replication-peer identity.
  • Ignorance of the migration cost. The author didn't think addresses would ever move.

All of these are recoverable, but only if the platform operator notices before the migration happens and provides the bridge (as Fly did with in-init address mapping).

Seen in

Last updated · 200 distilled / 1,178 read