QueueWaves

Research cascade-monitoring application for microservice architectures. QueueWaves models each service as a phase oscillator driven by its request queue depth. It emits alerts when configured coherence, regime, or chimera thresholds are crossed. A threshold crossing is not proof that a cascade is in progress, and this repository does not establish prospective lead time over ordinary service telemetry.

Pipeline position

QueueWaves is a complete SPO application — it instantiates the full pipeline from data collection to alerting:

Prometheus/StatsD (queue metrics)
         │
         ↓
   Collector.poll()
         │
         ↓
   InformationalExtractor → PhaseState[]
         │
         ↓
   CouplingBuilder.build() → K_nm
         │
         ↓
   UPDEEngine.step() → phases
         │
         ↓
   compute_order_parameter() → R
         │
         ↓
   RegimeManager.evaluate() → Regime
         │
         ↓
   detect_chimera() → chimera_index
         │
         ↓
   Alerter → Slack / PagerDuty / webhook

Architecture

Collector → Pipeline → Detector → Alerter
   │            │          │          │
 Prometheus   phase     chimera    Slack/
 /StatsD    extraction  + regime   PagerDuty
            + UPDE      analysis   webhook

The collector polls queue metrics, the pipeline extracts phases and runs UPDE integration, the detector evaluates synchronisation health, and the alerter fires notifications when thresholds are crossed.

Theory

Microservice queue depths oscillate around steady state. In normal operation, these oscillations are loosely synchronised (R ≈ 0.4-0.7). When a cascade develops:

1. Upstream services accumulate requests (queue depth rises)
2. Downstream services starve (queue depth falls)
3. R drops sharply as phase coherence breaks

QueueWaves can surface the R drop for investigation. Any lead-time, false-alarm, or intervention benefit must be measured on a representative service trace against ordinary queue, error-rate, and latency baselines before operational use.

Configuration

::: scpn_phase_orchestrator.apps.queuewaves.config

Pipeline

::: scpn_phase_orchestrator.apps.queuewaves.pipeline

Detector

::: scpn_phase_orchestrator.apps.queuewaves.detector

Alerter

::: scpn_phase_orchestrator.apps.queuewaves.alerter

Collector

::: scpn_phase_orchestrator.apps.queuewaves.collector

Server

::: scpn_phase_orchestrator.apps.queuewaves.server

Operational interpretation

QueueWaves is a reference application of the same reusable SPO pipeline, so this page should be read as a production playbook example, not a side experiment.

The full cascade-response loop depends on three invariants:

• deterministic extraction,
• bounded synchronization metrics,
• auditable alert generation.

That pattern allows teams in service operations to test "is this model behaving like a control instrument" before adding new collectors, targets, or alert channels.

In this setup, the alert layer is the last mile. The earlier layers are responsible for making sure phase and coupling evidence is structurally valid before escalation.

Business interpretation

QueueWaves demonstrates how the SPO control contract translates into service operations workflows:

• telemetry normalisation,
• phase extraction,
• synchrony risk scoring,
• deterministic escalation handoff.

The goal is not perfect prediction of every incident. It is early, explainable detection with bounded false-merge behaviour and auditable alert evidence.

For operations teams, this page is useful as a reference implementation pattern: same engine, different domain surface, predictable failure boundaries.