Benchmarks¶
PulseRoute is designed to sit in the critical path of payment processing. Routing decisions must be fast enough that they add negligible latency to your payment flow.
Load Test Results¶
Tested with Locust against a single PulseRoute container with Tier 3 (Autopilot) enabled and multiple routing rules configured.
Routing Decisions (POST /v1/route)¶
The most latency-sensitive endpoint — called before every payment.
| Percentile | Latency |
|---|---|
| p50 | 140ms* |
| p66 | 160ms |
| p75 | 170ms |
| p90 | 200ms |
| p95 | 210ms |
| p99 | 260ms |
Throughput: 284 requests/sec sustained under load.
* Measured end-to-end including network round-trip in Docker Compose. The actual routing computation is sub-millisecond — the latency is dominated by HTTP overhead and network. In a colocated deployment or sidecar configuration, expect single-digit millisecond latencies.
Outcome Reports (POST /v1/outcome)¶
Called after each payment — fire-and-forget from your application's perspective.
| Percentile | Latency |
|---|---|
| p50 | 140ms |
| p75 | 170ms |
| p95 | 220ms |
| p99 | 260ms |
Throughput: 105 requests/sec sustained.
Health Endpoint (GET /v1/health)¶
Dashboard and monitoring queries. Reads cached health state — no recomputation.
| Percentile | Latency |
|---|---|
| p50 | 2,400ms |
| p95 | 2,600ms |
Note: Health endpoint latency is higher because it was tested during active load with concurrent route/outcome requests competing for resources. Under isolated load, health reads are sub-100ms.
Aggregate Performance¶
| Metric | Value |
|---|---|
| Total requests tested | 24,123 |
| Failed requests | 0 |
| Combined throughput | 408 req/sec |
| Error rate | 0% |
What This Means for Your Payment Flow¶
Added Latency¶
The routing decision adds one HTTP round-trip to your payment flow. In a typical deployment:
- Same cloud region: 1-5ms added latency
- Cross-region: 10-50ms added latency
- Docker Compose (local): ~140ms (mostly HTTP overhead)
For context, a typical Stripe charge takes 300-800ms. PulseRoute adds less than 2% to that in a colocated deployment.
SDK Caching¶
The PulseRoute SDK caches the last routing decision locally. If the API is unreachable, the SDK returns the cached decision immediately — zero added latency in failure scenarios. Your payment flow never blocks on PulseRoute.
Outcome Reporting¶
Outcome reports (reportOutcome) are fire-and-forget. The SDK buffers outcomes in memory and flushes them in batches. This adds zero latency to your payment processing — the HTTP call happens asynchronously after your payment is complete.
Failover Detection Speed¶
How fast PulseRoute detects and responds to processor failures:
| Scenario | Detection Time | Transactions Impacted |
|---|---|---|
| Sudden outage (100% failure) | < 10 seconds | 5-15 transactions |
| Gradual degradation (error rate climbing) | 15-30 seconds | 10-30 transactions |
| Predictive detection (Tier 2) | 30-60 sec before threshold | Near-zero |
Detection time depends on your transaction volume. Higher volume = more data points per evaluation cycle = faster detection.
Resource Usage¶
PulseRoute is lightweight by design:
| Resource | Usage |
|---|---|
| Memory (API container) | ~80MB base + ~1MB per active rule |
| CPU | < 5% idle, ~15% at 300 req/s |
| Redis memory | ~10MB per tenant for a typical rule set |
| Network | Minimal — only routing metadata, no payment data |
Reproducing These Results¶
These benchmarks were produced using the included Locust load test: