Fintech Traffic Routing: 3 Stable Regional Hostnames Plus a Node.js Flag

Use three fixed regional hostnames, keep the public hostname unchanged, and let a server-side flag choose which regional origin receives each eligible request. For a fintech migration, the decision rule is stricter than "the new region responds": move traffic only when DNS, application, and email-authentication evidence all pass the same release gate.

Recommendation: use fixed origins such as us.example.test, eu.example.test, and ap.example.test behind one customer-facing name, then make the Node.js flag the migration control. Treat DNS as the stable naming layer, not as a fine-grained experiment engine. This keeps rollback independent of a registrar-specific API and produces evidence a small team can review before the next weekly release.

How should coarse regional routing plus stable hostnames work?

A DNS change can show that a name now resolves through a different configuration. It cannot, by itself, show that the intended fintech request reached the intended application node, that the node enforced the expected tenant policy, or that mail sent for the domain still aligns with its authentication policy. Those are separate claims, so they need separate observations.

This distinction matters during a registrar exit. The old control plane may have combined registration, authoritative DNS editing, redirects, and mail-related records behind one API. Reproducing its calls elsewhere proves very little. The deliverable is a portable zone and a documented traffic decision, with enough evidence to explain every cutover.

DNS alone can't provide that proof.

I use a compact gate because the revenue-per-hour calculation is unforgiving. A bespoke global scheduler might be interesting, but it competes with features customers can buy. Three coarse regions cover the stated problem. Outsource the undifferentiated DNS hosting work, keep the routing contract in code, and ship weekly.

The evidence bundle for one change should answer four questions:

1. Did the public hostname remain stable?
2. Which flag revision selected the regional origin?
3. Did the origin report the expected region and request identifier?
4. Were the domain's mail-authentication records preserved and reviewed?

The fourth item is easy to miss. DMARC is a domain-level policy and reporting mechanism built on SPF and DKIM identifiers. RFC 7489 also describes identifier alignment. A zone migration that preserves web traffic while carelessly changing mail-related records has not preserved the domain's behavior. For a fintech system, that is a release blocker, not cleanup for later.

The 2 criteria that decide the design

The first criterion is evidence locality. A useful traffic record should tie a request ID, flag revision, selected region, and responding origin together. Keep that record near the application decision. Resolver logs cannot explain a per-tenant flag choice, and application logs cannot prove what a resolver observed. Do not pretend one telemetry stream answers both questions.

The second is rollback independence. The rollback used during the migration should not require the API being retired. If a registrar-specific mutation is still in the emergency path, the system has not actually left that dependency. Fixed regional origins make this simpler: validate them ahead of time, then roll the application flag back to its previous revision without renaming the customer-facing host.

There is a trade-off. Application flags can make decisions at request time, but they add a hop or dispatch step to the serving path. DNS-weighted routing moves that choice out of the app, but cached answers make observations less direct and prevent request-level cohort selection. For a coarse three-region migration where audit evidence is the primary axis, I would accept the explicit application decision.

Keep the flag payload boring. A versioned map is easier to review than rules that quietly depend on IP geolocation, device traits, or an expanding list of exceptions. Start with a default region and named cohorts. Every request must have a deterministic fallback.

No guesswork.

A small Node.js routing contract

This example models the flag as data and refuses unknown regions before any request is sent. The host allowlist is part of the deployable artifact, so a malformed flag cannot turn the router into an arbitrary proxy. The sample uses reserved .test names and Node.js built-ins; replace the lookup and forwarding boundaries with the equivalents in your stack.

import { randomUUID } from "node:crypto";

type Region = "us" | "eu" | "ap";

type TrafficFlag = {
  revision: string;
  defaultRegion: Region;
  tenantRegions: Readonly<Record<string, Region>>;
};

type RouteEvidence = {
  requestId: string;
  tenantId: string;
  flagRevision: string;
  selectedRegion: Region;
  origin: string;
};

const origins: Readonly<Record<Region, URL>> = {
  us: new URL("https://us.example.test"),
  eu: new URL("https://eu.example.test"),
  ap: new URL("https://ap.example.test"),
};

export function selectOrigin(
  tenantId: string,
  flag: TrafficFlag,
): { url: URL; evidence: RouteEvidence } {
  const selectedRegion = flag.tenantRegions[tenantId] ?? flag.defaultRegion;
  const url = origins[selectedRegion];

  if (!url) {
    throw new Error(`Rejected unknown region for flag ${flag.revision}`);
  }

  return {
    url,
    evidence: {
      requestId: randomUUID(),
      tenantId,
      flagRevision: flag.revision,
      selectedRegion,
      origin: url.hostname,
    },
  };
}

Do not log account balances, payment details, authorization headers, or full request bodies with this evidence. The identifiers above establish the routing decision without turning an operational record into a second store of financial data. If tenant identifiers are sensitive in your environment, log an approved opaque identifier instead.

The forwarding boundary should attach the request ID to the internal call and require the origin to return its region identity. Compare that response with selectedRegion. A successful status from the wrong region is a failed routing check. Sharp edge.

Test the contract as a table: a mapped tenant goes to its assigned region, an unmapped tenant goes to the default, and invalid external flag data is rejected during parsing before it reaches selectOrigin. Also test a complete rollback by loading the prior flag revision. Unit tests establish determinism; a staged request through the public hostname supplies deployment evidence.

Building the cutover record

Before changing production traffic, export the zone into a provider-neutral review artifact and classify records by purpose: public application, regional origin, ownership verification, and email authentication. Compare names, record types, and values. Avoid using a screenshot as the only record; it is difficult to diff and easy to omit from the next migration. Then validate each regional origin directly. The check should exercise the same TLS name and application health contract that the router will use. A bare network connection is weak evidence because it skips the application identity. Record the deployment version and region returned by the origin, but keep secrets and customer data out of the output. For the release itself, choose a named internal cohort, publish a new immutable flag revision, and retain the prior revision. Observe routing evidence for that cohort. Expand only after the expected and observed regions agree. DNS changes, if any are required for the stable public name, get their own change record and verification; don't infer DNS success from application success.

Rollback is one action: restore the previous flag revision. The regional names remain available for diagnosis, while customers continue using the same public hostname. This division also makes ownership legible when one person is on call. The DNS layer owns names. The flag owns intent. The router owns enforcement. Evidence links the three.

Keep it dull.

Email needs a parallel review. Preserve the records used by sending systems and inspect aggregate DMARC reports after the migration window. RFC 7489 defines aggregate feedback as part of DMARC, but the report is later evidence, not permission to skip the pre-change comparison.

When the runner-up is better

DNS-weighted routing is the better choice when the desired unit is a broad population rather than a tenant or request cohort, and the application should not contain a regional dispatch layer. It can also fit systems where every origin is behaviorally interchangeable and the release process already measures resolver-visible changes. The cost is control granularity: a flag flip and a DNS answer do not share the same timing model.

Client-visible regional URLs are better when users must explicitly select a legal or operational boundary and that selection belongs in the product contract. They expose the region clearly, but they give up the stable-hostname requirement and create more URLs for clients to store and integrations to configure.

Neither option is universally safer. Pick the mechanism whose evidence matches the decision you must defend. For this migration, that decision is which approved fintech cohort reached which of three prevalidated origins under a named flag revision, while the public domain and its mail controls stayed intact. Fixed origins plus an application flag answer it directly.

References

• RFC 7489, Domain-based Message Authentication, Reporting, and Conformance (DMARC): https://datatracker.ietf.org/doc/html/rfc7489