[IDEA] Fluxgate K8S Expansion - Architecture Discussion

[rojae]

Overview

Exploring options to expand Fluxgate into a Kubernetes-native rate limiting solution
that works at the network level, rather than application level.

Current State

• Fluxgate is a Java/Spring-based rate limiting library
• Works at application level (filter/interceptor)
• Supports dynamic rules, hot reload, multiple algorithms

The Challenge

envoyproxy/ratelimit already exists as a Go-based rate limit service for Envoy. Simply rewriting Fluxgate in Go would not provide meaningful differentiation.

Potential Differentiation

Existing Solutions	Fluxgate Could Offer
Static config files	Dynamic rule management via CRD
Simple descriptor matching	Complex condition rule engine
Limited algorithms	Multiple algorithms (Token Bucket, Sliding Window, etc.)
Manual config reload	Hot Reload without restart

Architecture Options

Option A: Control Plane Only (Go)

Leverage existing data plane, focus on dynamic rule management.

graph TD
    A[fluxgate-operator] --> B[envoyproxy-ratelimit]
    B --> C[Envoy Proxy]
    C --> D[Backend Services]
    E[Client] --> C

Loading

Option B: Full Stack with WASM (Go + Rust)

In-process rate limiting with full control over implementation.

graph TD
    A[fluxgate-operator] --> B[CRD RateLimitPolicy]
    A --> C[fluxgate-envoy-wasm]
    C --> D[Envoy Proxy]
    D --> E[Backend Services]
    F[Client] --> D

Loading

Performance Comparison

Approach	Latency
External gRPC	2-10ms
WASM In-Process	0.1-0.5ms

Open Questions

1. Is there enough differentiation to justify a new project?
2. Should we focus on Control Plane only, or build Data Plane too?
3. What unique features would make this valuable to the community?

Tech Stack Consideration

• Go: K8s Operator, practical choice, large ecosystem
• Rust: WASM Filter, performance critical, steeper learning curve

Related

• envoyproxy/ratelimit
• Istio WasmPlugin
• Proxy-WASM Rust SDK