Architecture

RouteSeam is two systems that fail independently. That separation is the product’s central reliability promise: your redirects do not depend on the dashboard, the API, or the database being up. This page explains the pieces at the level that matters to you.

Control plane vs. data plane

flowchart LR
    subgraph CP["Control plane"]
        R["Dashboard, API, billing,<br/>DNS verification, config publishing"]
    end
    subgraph DP["Data plane (edge)"]
        C["Caddy — automatic HTTPS"] --> E["Redirect engine —<br/>in-memory routing table"]
    end
    CP -. "publish config versions" .-> DP
    DP -. "telemetry events" .-> CP
    V["Visitor"] --> DP

The control plane is everything you interact with: the dashboard, the public API, DNS verification, billing, and analytics.

The data plane is the edge: the infrastructure that actually answers visitor requests. It terminates HTTPS and returns the 301/302/307/308 response from an in-memory routing table — a constant-time hostname lookup, with no database query on the request path.

Nothing on the redirect path touches the control plane. A request goes DNS → edge → redirect response, entirely within the edge.

Why the separation matters

The cardinal rule of RouteSeam’s design: control-plane failure must never stop existing redirects. If the dashboard is down for maintenance, the database is unavailable, or billing systems are having a bad day, your live redirects keep serving — the edge runs from its own copy of the configuration, persisted locally. Certificate renewals also keep happening at the edge without control-plane involvement.

What you experience during a control-plane outage: redirects work, but changes do not propagate and analytics stop updating until service returns.

Edge config versions

The edge never reads your account data directly. Instead, the control plane publishes the routing configuration as immutable, versioned edge config versions:

You change something routing-relevant — add a domain, edit a destination, suspend a domain.
The control plane builds a new, complete configuration snapshot with a new version number.
The edge fetches the snapshot, verifies its checksum, and performs an atomic swap — requests see the whole old version or the whole new one, never a partial mix.
The edge reports back the version it is running, and the control plane records the sync status.

Because versions are immutable and monotonic, RouteSeam can tell at a glance whether the edge is current. Staleness triggers alerts — configuration drift is treated as an operational problem, not a silent condition.

Only verified, non-suspended domains are included in a snapshot, so suspending a domain removes both its routing and its certificate renewal within one publish cycle.

On-demand TLS

HTTPS is mandatory on RouteSeam — there is no HTTP-only mode. Certificates are issued automatically at the edge via Caddy and Let’s Encrypt, with no action from you beyond the DNS record.

Issuance is gated by the edge configuration: a certificate is only obtained for a hostname that appears in the published config. Strangers pointing random domains at RouteSeam cannot trigger issuance, and a suspended domain loses renewals too. Renewals happen at the edge and do not depend on the control plane being up.

Analytics pipeline

Analytics never sit on the redirect critical path. The edge writes the redirect response first and records an event asynchronously — fire-and-forget. Events are batched and shipped to the control plane, which rolls them up into the dashboard counters and breakdowns (requests today/7d/30d, top paths, top referrers, status codes). If the control plane is unreachable, a bounded amount of analytics data may be dropped — redirects and their latency are never affected. See analytics for what is measured.

Eventual consistency

RouteSeam is eventually consistent: changes are not instant, but they are fast. When you save a change, a new config version is published and the edge applies it — typically live within seconds, not minutes. A few implications:

Right after you edit a destination, a request may briefly still hit the old one while the new version propagates.
The domain status pill reflects the same pipeline: a domain you just verified shows its progression as the config publishes.
Deleting or disabling a route removes it from the next version, on the same seconds-scale timeline.

Domain lifecycle — the states a domain moves through as config publishes authorize DNS verification and TLS.
Organizations — the ownership model the control plane manages.
Roadmap — where the platform goes from here.