Routing Engine

The high-performance core of the ApiReverseProxy that determines where to send incoming traffic.

The Identifier Pattern

The Gateway uses a mandatory prefix pattern for all public traffic to ensure multi-tenancy and environment isolation.

https://api.yourgateway.com/{tenant}/{catalog}/{environment}/{...path}

The Resolution Algorithm

When an HTTP request hits the proxy, the routing engine follows these steps:

Path Normalization: Consecutive slashes are removed and the URL is decoded.
Identifier Extraction: The first three segments of the path are extracted as:/{tenant}/{catalog}/{environment}/...
Database/Cache Lookup: The proxy queries for an active environment linked to a catalog and tenant with those unique identifiers.
Endpoint Match: The remainder of the path is matched against the revision_endpoints associated with that specific environment's published revision.

Performance First

Route resolutions are cached in memory for 60 seconds. This means even with thousands of tenants and complex regex routes, the proxy overhead is typically under 1ms.

SQL Pattern Matching

The matching is done efficiently at the database layer (and subsequently cached) using PostgreSQL's regex operator (~). The curly-brace parameters in your configuration (e.g., /users/{id}) are automatically converted to [^/]+ for the match.

Query Sample

SELECT * FROM revision_endpoints WHERE @path ~ ('^' || regexp_replace(pattern, '\{[^}]+\}', '[^/]+', 'g') || '$') ORDER BY length(pattern) DESC LIMIT 1;

Path Specificity

To avoid ambiguity, exact path matches (no parameters) are always prioritized over parameterized paths. If multiple parameterized paths match, the longest path (most specific) wins.