Routing Concepts
Crate uses a high-performance radix-tree router (O(1) lookup) powered by Go’s standard library. This architectural choice ensures that routing overhead remains negligible even as your API grows to thousands of paths.
Matching Logic
Routes are matched based on a combination of hostnames and paths, with a “most-specific-match” priority:
- Hosts: Supports specific domains (
api.crate.cc), wildcard subdomains (*.crate.cc), and multi-level wildcards. - Paths: Supports static paths (
/v1/health) and prefix matches (/v1/users/*).
Specific host matches always take precedence over wildcards, and longer path matches take precedence over shorter ones (the Longest Prefix Match rule).
Load Balancing Strategies
Traffic distribution is managed at the routing layer with built-in resilience:
- Round Robin: Requests are distributed sequentially to each healthy upstream.
- Weighted Round Robin: Assign more traffic to your beefier servers and less to smaller instances.
- Power of Two: We pick two random servers and choose the one with the fewest active connections.
- Header Based (Sticky): Hashes a specific header (e.g.,
User-ID) to ensure a user always lands on the same server. - Header Match: Directs traffic with specific header values (e.g.,
x-channel: beta) to a dedicated backend. - Waterfall: Fills targets sequentially. Saturates Server 1, then spills over to Server 2, and routes the rest to Server 3.
Advanced Path Rewriting
Decouple your public API surface from your internal microservice architecture using our rewriting engine:
- Strip Prefix: Automatically remove versioning tags or routing hints before forwarding (e.g.,
/api/gateway/users->/users). - Path Prepending: Add internal namespace prefixes required by your mesh.