CONCEPT Cited by 1 source

Single-endpoint abstraction

Definition

Single-endpoint abstraction is the architectural principle of giving clients one stable address for a heterogeneous or dynamically-changing backend fleet, and hiding all cluster identity / capacity / topology behind that address. Clients connect to the abstraction; a gateway or proxy behind the abstraction decides which actual backend handles each request.

This is a decoupling discipline: it separates "what do clients depend on?" (the endpoint) from "what does the backend look like?" (the fleet).

What it buys

Once the client endpoint is stable, the gateway / proxy can:

1. Substitute backends without breaking clients. Blue/green cluster swaps, canary deployments, and in-place version upgrades all become invisible to clients (patterns/no-downtime-cluster-upgrade).
2. Change capacity without client coordination. Adding / removing backend clusters is an operator action, not a user-visible migration. "Transparent change of capacity … without user interruptions" (sources/2026-03-24-expedia-operating-trino-at-scale-with-trino-gateway).
3. Route dynamically. Different clients / queries / tenants can land on different backends under the same endpoint (concepts/workload-aware-routing).
4. Apply cross-cutting policy. Auth, rate limiting, observability, caching all attach at the gateway in one place.

Without single-endpoint abstraction, each of these operations is a client-visible migration — every BI dashboard, every scheduled job, every ad-hoc user has to update its connection URL. At scale this is intractable.

Where it shows up

• Trino Gateway — one connection URL for a Trino cluster fleet; gateway routes to the right cluster per query. Enables blue/green cluster upgrades and capacity changes without touching client configs. (sources/2026-03-24-expedia-operating-trino-at-scale-with-trino-gateway)
• Envoy / ECS Service Connect / Amazon API Gateway — the same pattern at the service-to-service layer.
• DNS-level abstraction (a CNAME in front of a fleet) is a weaker form — it hides IPs but still exposes one backend instance per DNS answer, and has TTL-governed lag when the backend fleet changes.
• Weighted DNS traffic shifting (Figma) uses single-endpoint abstraction at the DNS layer to shift between ECS and EKS fleets during migration.

Required conditions

1. The gateway has to terminate and understand the protocol. TCP-only LBs can give you a single port but not a single endpoint abstraction in this sense — they can't substitute dissimilar backends because they can't inspect the connection.
2. The gateway must not be a single point of failure. If the endpoint itself fails, every client sees it. The gateway tier usually has its own redundancy discipline (multi-AZ, active-active, health-checked).
3. Backend addresses must be substitutable. Clients must not cache or hardcode backend hostnames; the abstraction only works if clients actually depend on the endpoint, not the backend.

Seen in

• sources/2026-03-24-expedia-operating-trino-at-scale-with-trino-gateway — the four advantages listed in the post (single connection URL, automatic routing, no-downtime upgrades, transparent capacity changes) are direct consequences of the single-endpoint abstraction.

Related

• concepts/workload-aware-routing — the companion property on the dispatch side.
• patterns/query-gateway — the SQL-engine-specific realisation.
• patterns/no-downtime-cluster-upgrade — the canonical upgrade strategy the abstraction enables.