Skip to content

Test setup

fluxgo is evaluated on a chain of four Go microservices where every outbound call goes through a circuit breaker and a fault-injection proxy.

k6 load generator
│
▼
gateway :8080 ──Toxiproxy :8481──▶ auth :8081 ──Toxiproxy :8482──▶ user :8082 ──Toxiproxy :8483──▶ notification :8083
[breaker] [breaker] [breaker] (terminal service)
  • Three breakers, one per hop (gateway → auth, auth → user, user → notification). Each is either fluxgo or gobreaker, chosen at startup with CB_MODE.
  • Toxiproxy sits on every link so latency, timeouts, bandwidth limits or a full outage can be injected between any two services.
  • k6 drives the load against the gateway.
  • Every service logs one JSON line per request and exposes its breaker state at GET /debug/cb (see Snapshot).

Each scenario runs under two resource limits per container, to see how the breakers behave when the services are starved.

ProfileCPUMemory
Spec-A (standard)2 vCPU2048 MB
Spec-B (constrained)0.5 vCPU256 MB

For a fair comparison, gobreaker’s static trip ratio equals fluxgo’s baseline threshold, and both share the same recovery timeout and half-open quota:

Settinggobreakerfluxgo
Trip thresholdfailure ratio ≥ 0.6 or 5 consecutive failuresθₜ around ThetaBase = 0.6, adaptive
Open → Half-OpenTimeout = 60sRecoveryTimeout = 60s
Half-Open probesMaxRequests = 1HalfOpenMaxRequests = 1
ScenarioLoadFaultWhat it measures
Normal loadSteady, 5 minNoneFalse trips and overhead on a healthy system
Traffic spike10 → 250 virtual users in 10 sBandwidth limitFalse trips under a legitimate spike
Gradual degradationSteady, 5 minLatency +50 ms … +500 ms on user → notificationHow early the breaker reacts to slow decay
Sudden failureSteady, 3 minTimeout at second 60Detection delay on a hard outage

Each scenario is repeated for both breakers, alternating which one runs first to avoid thermal or caching bias. See Metrics for how runs are scored.