Yaogress

Keep complete routing intent in one record

Configuration owners use the protected registration API to maintain stable service identifiers. Each record contains a name, complete hostname rules and all backends. Backends may use HTTP or HTTPS; the business listener is internal HTTP. Public TLS encryption and external ingress are independently operated.

Updating a service record completely replaces it, and deletion removes all route keys for that ID. A conflict in any replacement key rejects the entire change and preserves the old record. Restart restores complete registrations from durable storage; unavailable state is never represented by an empty registry.

Submit domains and backends as one complete record

A service needs a stable service ID, a service name, its complete domain selection and all backend addresses. Exact declares explicit suffixes. Any covers other admissible suffixes for the same service name. They are not primary and standby choices for a failed connection.

Prepare the complete record from the application’s actual ingress needs before submitting a change. A later read can confirm the current configuration, but it cannot establish when an earlier timed-out submission completed. It is a current observation and does not establish backend readiness.

1. Define the complete route scope

   Select the service name, every domain suffix and the full HTTP or HTTPS backend set. Do not treat related entry points as independent partial updates.

2. Submit the whole record

   A conflict on any route key rejects the replacement and retains the original record with every binding. Resolve the conflict before choosing a new complete declaration.

3. Verify the actual Host

   Send requests using the complete domains that must be supported, and inspect the matched service, fixed backend and business response together.

Match the hostname, then freeze the destination

The HTTP Host header names the requested host. Its first label is the service name and the remaining labels form the suffix: api.example.com means api and example.com. Exact matches only explicitly listed combinations. Any accepts other valid suffixes for that name when an Exact entry is absent.

The gateway reads one coherent snapshot and selects one backend after matching the service record. A failed connection to an Exact match does not fall back to Any. The original Host, path and query retain their application meaning; routing does not strip, decode or reorganize application paths.

Use load hints for a single selection

A service’s complete registered backend set always remains eligible. Explicitly enabled endpoints can report their current business request count. A successful observation creates a short-lived in-memory sample. Failure, expiry or a disabled probe means no usable hint, without removing the endpoint.

For multiple backends, select two distinct candidates at random. Compare request counts only when both have fresh enabled samples, preferring the lower count. Otherwise choose randomly between the pair. Missing data is not zero load, and an instrumented endpoint has no automatic preference.

Stream the exchange and preserve failure meaning

Requests and responses stream incrementally, with backpressure slowing a sender when the receiver cannot keep up. The gateway does not collect the complete request or response body. It handles connection and header responsibilities for each hop; authentication, cookies, sessions and cross-origin policy remain with the application or independent edge.

A possibly dispatched request is never automatically replayed or sent to another backend. Even a 502 does not prove that the backend received nothing or produced no effect. After response handoff to the ingress transport, a later body failure leaves an incomplete response rather than replacing its status.

Distinguish route absence, forwarding failure and business rejection

Begin investigation with whether the request matched a service, then inspect the frozen backend and error source. No matching route, failure to establish an upstream connection, a backend’s business error and an interrupted response body occur at different stages and require different next actions.

For a request that may write business state, the application must investigate the original business identity after failure. The gateway does not own business idempotency, and changing backends or falling back to Any cannot resolve uncertainty. Load samples inform one selection; they are not health checks or permission for a safe replay.

• Supported conclusion: diagnostics identify the original selection

  The matched service and selected backend explain where this request was directed, while gateway errors remain distinct from original backend responses.

• Unsupported conclusion: 502 means the business action never ran

  The request may have reached the backend or produced effects. An error status does not authorize another execution of a write.

• Check next: a load hint is missing or expired

  The backend remains a candidate. Missing data is neither zero load nor evidence that the endpoint was removed.

Explain requests with the facts selected at the time

Business diagnostics retain requested Host, matched service, selected backend, method and timing, while redacting paths and queries entirely. Headers, cookies and bodies are not recorded. Gateway errors carry a reserved marker; a backend error retains its application origin. Status alone cannot distinguish them.

Specified verification covers complete replacement, Exact precedence, expired samples, bidirectional streaming, no replay after dispatch and diagnostic redaction. Operational dashboards count stored observations. Missing intervals remain gaps, with no claim of lossless traffic totals or current health. Actual records must establish the applicable results.