Docs
Wave Flow
Overview

Wave Flow Overview

Wave Flow is Wave's priority-based traffic protection system that protects critical services during high load by intelligently shedding less important traffic. By deploying directly into your service mesh as WebAssembly (WASM) modules, Wave Flow provides granular, low-latency traffic protection without additional sidecars or infrastructure overhead.

What is Wave Flow?

Wave Flow implements priority-based traffic protection, a strategy that categorizes incoming requests into priority tiers (CRITICAL, IMPORTANT, MODERATE, BULK) and automatically drops lower-priority traffic when your services are under stress. This ensures your most critical business functions remain available even when infrastructure capacity is constrained.

Unlike traditional rate limiting or circuit breakers that treat all traffic equally, Wave Flow makes intelligent decisions about which requests to serve based on business priority, not just how many requests to allow through.

Key Benefits

  • Protects Revenue-Critical Traffic: Ensures checkout, payment, and authentication flows remain available during traffic spikes
  • Zero Infrastructure Overhead: Deploys as WASM modules directly into existing service mesh proxies (no new pods, no new sidecars)
  • Sub-Millisecond Latency: Native WASM execution adds negligible overhead compared to external rate limiters
  • Fine-Grained Control: Match rules based on HTTP headers, paths, and methods for precise traffic classification
  • Service Mesh Native: Works with Istio, Linkerd, Kuma, Consul, and major API gateways (Kong, NGINX, Envoy, APISIX)
  • Dynamic Configuration: Update traffic rules without redeploying services or restarting proxies
  • Real-Time Metrics: Monitor shedding decisions and protected traffic through Wave dashboard

How It Works

Architecture Overview

⚠️

Prerequisites: Wave Flow requires a Proxy-WASM compatible proxy or service mesh. Supported options include:

  • Istio (Ingress Gateway, Sidecar, or Ambient Waypoint)
  • Linkerd, Kuma, Consul (service meshes)
  • Kong Gateway, NGINX Ingress, Envoy Gateway, APISIX (API gateways)

Wave Flow deploys as a WebAssembly (WASM) module that runs inside these proxies to intercept and control traffic.

Wave Flow Architecture Diagram

Request Flow

Request Arrives

Client makes HTTP request to ingress gateway or service mesh proxy

WASM Filter Intercepts

Wave Flow WASM module intercepts request before routing

Priority Classification

Request is matched against configured priority class rules:

  • Check HTTP headers (e.g., X-User-Type: premium)
  • Check URL paths (e.g., /checkout/*, /api/v1/payment)
  • Check HTTP methods (GET, POST, PUT, DELETE)

Shedding Decision

Based on classified priority and current system load:

  • CRITICAL: Never shed (always allowed)
  • IMPORTANT: Shed only under extreme load (auto mode)
  • MODERATE: Shed proactively when capacity is constrained
  • BULK: Shed aggressively to protect higher-priority traffic

Response

Request outcome:

  • Allowed: Request proceeds to backend service
  • Rejected: Returns HTTP 503 (Service Unavailable) immediately

Deployment Modes

Wave Flow can be deployed in three configurations:

Ingress Gateway Mode (Recommended for Most Use Cases)

Deploy Wave Flow to your ingress gateway (Istio, Kong, NGINX, Envoy, etc.) to protect all traffic entering your cluster. This is the most common deployment pattern as it provides cluster-wide traffic control at the entry point.

  • Scope: All traffic entering the cluster
  • Use Case: Protect entire application from external load
  • Configuration: Single policy set applied to ingress gateway
  • Supported Gateways: Istio Ingress Gateway, Kong Gateway, NGINX Ingress, Envoy Gateway, APISIX

Use Cases

E-Commerce: Protect Checkout During Flash Sales

Problem: During Black Friday flash sales, your checkout API becomes overloaded. Users can browse products but can't complete purchases, resulting in lost revenue.

Solution: Configure Wave Flow to prioritize checkout and payment flows:

  • CRITICAL: /checkout/*, /payment/* paths
  • IMPORTANT: /cart/*, /api/v1/orders
  • MODERATE: /products/*, /search
  • BULK: /recommendations, /similar-items

Result: Checkout remains available for users ready to buy, while product browsing and recommendations are shed to protect capacity.

SaaS Platform: Protect Paid Users During Traffic Spikes

Problem: Free tier users overwhelm your API during a marketing campaign, degrading service for paying customers.

Solution: Use HTTP headers to classify traffic:

  • CRITICAL: X-User-Tier: enterprise (enterprise customers)
  • IMPORTANT: X-User-Tier: pro (pro users)
  • MODERATE: X-User-Tier: free (free tier users)
  • BULK: Unauthenticated requests

Result: Paying customers experience zero degradation while free tier traffic is shed to protect capacity.

Financial Services: Ensure Critical Transaction Processing

Problem: Market volatility drives massive traffic to trading platform, but only a small fraction are actual trades. Most requests are portfolio views and price checks.

Solution: Prioritize transaction endpoints:

  • CRITICAL: POST /api/v1/trades, POST /api/v1/orders
  • IMPORTANT: GET /api/v1/portfolio, GET /api/v1/balance
  • MODERATE: GET /api/v1/market-data
  • BULK: GET /api/v1/news, GET /api/v1/analytics

Result: Trade execution is never blocked, while non-critical data fetching is shed during peak load.

Healthcare: Prioritize Emergency Care Systems

Problem: Electronic health record (EHR) system experiences load spikes during shift changes. Emergency room systems must remain responsive.

Solution: Classify by department and urgency:

  • CRITICAL: X-Department: emergency, X-Department: icu
  • IMPORTANT: X-Department: surgery, X-Department: cardiology
  • MODERATE: X-Department: outpatient
  • BULK: Administrative and scheduling systems

Result: Life-critical systems remain available even when administrative systems are shedding traffic.

Comparison with Alternatives

FeatureWave FlowTraditional Rate LimitingCircuit BreakerAPI Gateway Rate Limit
Priority-Based✅ Yes (4 tiers)❌ No (all traffic equal)❌ No (all traffic equal)⚠️ Limited (quota-based)
Latency Overhead~0.1ms (WASM)~1-5ms (sidecar)~0.5ms (library)~10-50ms (external service)
Infrastructure CostZero (reuses proxies)High (additional sidecars)Low (library)High (API gateway)
Dynamic Rules✅ Real-time⚠️ Requires deployment⚠️ Requires deployment✅ Real-time
Service Mesh Native✅ Multi-proxy support❌ External❌ Code-level❌ External
Granular Control✅ Headers, paths, methods⚠️ IP-based❌ Binary (open/closed)⚠️ API key-based
Business Context✅ Priority classes❌ No❌ No⚠️ Limited

When to Use Wave Flow

Use Wave Flow When:

  • ✅ You use a Proxy-WASM compatible proxy (Istio, Envoy, Kong, NGINX, Linkerd, Kuma, Consul, APISIX)
  • ✅ Different traffic types have different business criticality
  • ✅ You need to protect revenue-generating flows during outages
  • ✅ You want infrastructure-level protection without code changes
  • ✅ Sub-millisecond overhead is critical for your latency budget

Don't Use Wave Flow When:

  • ❌ Your infrastructure doesn't support Proxy-WASM (requires compatible proxy or service mesh)
  • ❌ All your traffic is equally important (no prioritization needed)
  • ❌ You prefer application-level rate limiting in code
  • ❌ You need advanced quota management (use API gateway instead)

Next Steps

Ready to protect your critical services with Wave Flow?

  1. Getting Started Guide - Step-by-step setup and first policy configuration
  2. Priority-Based Traffic Protection - Deep dive into traffic classes and shedding strategies
  3. Integration with Autopilot - Combine with horizontal scaling for comprehensive protection

Questions? Wave Flow is production-ready and actively used to protect high-traffic applications. For implementation guidance specific to your architecture, consult the Wave documentation or contact support.