Chapter 2
Traffic Management and Advanced Routing
As modern API ecosystems become increasingly distributed and dynamic, traffic control and routing sophistication are paramount to both resilience and security. This chapter explores how Curiefense transforms simple request forwarding into a strategic, programmable function-balancing service discovery, performance, and policy enforcement across complex environments. You'll discover routing beyond the basics: mastering decisions based on protocol, intent, and real-time service conditions, while shaping, steering, and optimizing every packet's journey.
2.1 Layer 7 Routing Capabilities
Curiefense's Layer 7 routing capabilities provide a sophisticated framework to direct HTTP and HTTPS traffic based on application-layer attributes, enabling granular control over request handling far beyond traditional Layer 3 and Layer 4 mechanisms. These advanced routing mechanisms allow precise mapping of complex business requirements into declarative policies that inspect and act upon elements such as URI paths, host headers, HTTP headers, query parameters, and protocol-specific characteristics. This section explores the core constructs of Curiefense's Layer 7 routing, emphasizing how they facilitate surgical traffic steering and policy enforcement.
A fundamental component of Curiefense's routing logic is the use of path- and host-based rules, which form the primary criteria for directing inbound requests. Unlike basic routing systems that rely solely on prefix matching or host equality, Curiefense supports regular expressions and advanced pattern matching against the request URI path and host header. This enables scenarios such as routing based on partial matches, presence of specific URI segments, or domain wildcarding. Path rules can be expressed using POSIX-compliant regexes, allowing for high flexibility. For example, one can route requests to different backend services or security profiles depending on whether the URI path matches /api/v[0-9]+/ or /static/assets/, ensuring backend specialization according to application endpoints.
In addition to basic path and host conditions, Curiefense augments routing capabilities with fine-grained inspection of HTTP header attributes. Routing policies can incorporate matches on standard and custom headers using exact, prefix, suffix, or regex criteria. This includes common headers such as User-Agent, Accept-Language, or security tokens injected by identity providers. These header-based rules enable traffic segmentation by client type, geographic locale, or authentication status, supporting, for instance, staged feature rollouts to selected user agents or A/B testing contingent on header presence. Header attribute matches can be combined with path and host rules using logical AND and OR constructs, allowing intricate policy trees.
Beyond static pattern matching, Curiefense integrates protocol-specific logic into routing decisions. This encompasses evaluation of HTTP methods (e.g., GET, POST, PUT), query string parameters, and even HTTP/2 and HTTP/3 connection nuances. Routing policies can, for example, divert all POST requests targeting /transactions/ to more stringent processing chains or more powerful backend clusters capable of handling higher CPU usage. Query parameters can be inspected individually or in combination, enabling conditional routing based on dynamic client-provided data. This is particularly useful to enforce routing distinctions based on API versioning parameters or flags indicating requested services.
Curiefense's routing model embraces declarative configuration, allowing administrators to describe complex business logic succinctly and transparently within YAML policy files. Rather than encoding routing imperatives in custom code or network configurations, policies articulate intent through nested match expressions. Logical operators (all, any, and not) enable grouping of rule clauses to express both inclusive and exclusive conditions. This declarative approach enhances maintainability and auditability while reducing the risk of misconfiguration under operational changes.
To illustrate, consider an enterprise API gateway scenario where internal services require isolation from external clients, and certain premium endpoints are accessible only to authorized partners. A single routing policy can encode the following:
- Route all /internal/ path requests exclusively to internal backend pools, rejecting any request not arriving from trusted IP addresses.
- Route /partners/premium/ requests exclusively if a custom header X-Partner-Auth is present and valid.
- Send all remaining traffic matching /api/ paths to the public backend servers.
Such a policy is expressible in the Curiefense routing schema, combining host, path, header, and client address matches with logical conjunctions.
Another hallmark of Curiefense's Layer 7 routing is its support for dynamic routing decisions based on real-time attributes extracted during request processing. This includes routing driven by cookie values, JWT claims, or session identifiers, enabling adaptive behavior tailored to the authenticated user context. For example, users authenticated via different identity providers might be routed to distinct clusters with varying SLAs or logging capabilities. This dynamic evaluation empowers security policies and routing strategies to closely reflect operational requirements in complex environments.
Complex business requirements frequently demand multi-dimensional routing logic, such as combining Layer 7 attributes with Layer 4 context (IP reputation, geo-location) or integrating with external decision services. Curiefense's flexible policy engine supports extensions via custom WebAssembly (Wasm) modules, enabling bespoke protocol parsers or enrichment with external data sources before routing finalization. This extensibility ensures routing policies can evolve with emerging protocols and enterprise needs without compromising performance or security.
Curiefense's Layer 7 routing mechanisms constitute a powerful toolset for precise traffic control in modern application delivery environments. By enabling detailed inspection and combination of path, host, header, method, and protocol-specific attributes within a fully declarative configuration framework, it allows organizations to model sophisticated routing policies that align tightly with security, operational, and business objectives. This precision routing reduces attack surfaces, optimizes backend utilization, and supports seamless service differentiation critical to high-scale distributed architectures.
2.2 Traffic Steering and Load Balancing
Curiefense incorporates sophisticated traffic steering and load balancing mechanisms designed to optimize resource utilization, ensure high availability, and maintain seamless service continuity across heterogeneous backend infrastructures. The system's architecture facilitates dynamic load distribution while continuously monitoring backend health and topology changes, enabling adaptive decision-making at runtime.
At the core of Curiefense's traffic management lies the use of configurable load balancing algorithms, tailored to accommodate the varied performance characteristics and capacities of backend servers. These algorithms operate within a layered control plane, which aggregates real-time telemetry and health metrics gathered through active and passive probes. This information plays a critical role in steering decisions-routing requests to backends based on current load, latency, error rates, and server availability.
Load Balancing Algorithms
Curiefense supports several well-established algorithms for allocating incoming requests:
- Round Robin: The simplest baseline approach, distributing requests cyclically among available backend instances. This method assumes homogeneous backend capabilities and serves as a starting point for traffic distribution.
- Weighted Round Robin: Extends Round Robin by assigning weights to each backend, allowing disproportionate request volumes in proportion to the processing capacity or priority of individual servers. Weights can be statically configured or dynamically adjusted based on health checks.
- Least Connections: Prioritizes backends with the fewest active connections, balancing load more precisely in environments with variable request durations and backend service times. This algorithm reduces the likelihood of overloading slower or busier backend nodes.
- Weighted Least Connections: Combines weight assignment and active connection tracking to steer traffic towards backends that are both capable and currently...