|
| 1 | +<?php |
| 2 | + |
| 3 | +declare(strict_types=1); |
| 4 | + |
| 5 | +namespace Clegginabox\Airlock\Queue; |
| 6 | + |
| 7 | +use Clegginabox\Airlock\HealthCheckerInterface; |
| 8 | + |
| 9 | +/** |
| 10 | + * BackpressureQueue - Adaptive admission based on downstream health. |
| 11 | + * |
| 12 | + * THE CONCEPT: |
| 13 | + * ------------ |
| 14 | + * Normal queues admit at a fixed rate. Backpressure queues adapt based on |
| 15 | + * signals from downstream systems. If your database is slow, admit fewer |
| 16 | + * people. If it recovers, speed up again. |
| 17 | + * |
| 18 | + * Think of it like a tap that adjusts water flow based on how fast the sink |
| 19 | + * is draining. If the sink is backing up, reduce the flow. |
| 20 | + * |
| 21 | + * CORE IDEA: |
| 22 | + * ---------- |
| 23 | + * This is a DECORATOR around another queue. It doesn't replace FIFO/Lottery |
| 24 | + * logic - it wraps it and adds a "should we even try right now?" check. |
| 25 | + * |
| 26 | + * BackpressureQueue |
| 27 | + * └── wraps RedisFifoQueue (or any other queue) |
| 28 | + * |
| 29 | + * HEALTH SIGNALS - where does backpressure info come from? |
| 30 | + * -------------------------------------------------------- |
| 31 | + * Option A: External health checker (injected dependency) |
| 32 | + * - A service that polls your DB, API, etc. and returns a 0.0-1.0 health score |
| 33 | + * - Queue asks "what's the health?" before each peek/pop |
| 34 | + * |
| 35 | + * Option B: Redis key convention |
| 36 | + * - Something else writes to a Redis key like "backpressure:health" (0.0-1.0) |
| 37 | + * - Queue reads that key directly |
| 38 | + * - Simple, decoupled - a cron job or the app itself updates the key |
| 39 | + * |
| 40 | + * Option C: Self-measuring (advanced) |
| 41 | + * - Track how long admitted users take to release() |
| 42 | + * - If latency spikes, reduce admission rate |
| 43 | + * - Requires feedback loop from the Seal back to the Queue |
| 44 | + * |
| 45 | + * WHAT DOES "BACKPRESSURE" ACTUALLY CHANGE? |
| 46 | + * ----------------------------------------- |
| 47 | + * When health is low, you have choices: |
| 48 | + * |
| 49 | + * 1. THROTTLE PEEK/POP |
| 50 | + * - peek() returns null even if queue has people |
| 51 | + * - "Sorry, system is busy, try again shortly" |
| 52 | + * - Simple but blunt |
| 53 | + * |
| 54 | + * 2. PROBABILISTIC ADMISSION |
| 55 | + * - health = 0.3 means 30% chance peek() returns the real head |
| 56 | + * - Randomly skip turns based on health score |
| 57 | + * - Smoother degradation |
| 58 | + * |
| 59 | + * 3. DELAYED ADMISSION |
| 60 | + * - peek() returns head only if enough time has passed since last admission |
| 61 | + * - Low health = longer delays between admissions |
| 62 | + * - Rate limiting based on health |
| 63 | + * |
| 64 | + * |
| 65 | + * HEALTH CHECKER INTERFACE (you'll need this): |
| 66 | + * -------------------------------------------- |
| 67 | + * |
| 68 | + * interface HealthCheckerInterface |
| 69 | + * { |
| 70 | + * /** @return float 0.0 (dead) to 1.0 (fully healthy) |
| 71 | + * public function getScore(): float; |
| 72 | + * } |
| 73 | + * |
| 74 | + * // Simple Redis-based implementation: |
| 75 | + * class RedisHealthChecker implements HealthCheckerInterface |
| 76 | + * { |
| 77 | + * public function __construct(private Redis $redis, private string $key) {} |
| 78 | + * |
| 79 | + * public function getScore(): float |
| 80 | + * { |
| 81 | + * return (float) ($this->redis->get($this->key) ?? 1.0); |
| 82 | + * } |
| 83 | + * } |
| 84 | + * |
| 85 | + * WHO SETS THE HEALTH SCORE? |
| 86 | + * -------------------------- |
| 87 | + * That's outside this class. Could be: |
| 88 | + * - A middleware that tracks response times and writes to Redis |
| 89 | + * - A cron job that pings your DB and updates the key |
| 90 | + * - Your app's exception handler (errors spike = reduce health) |
| 91 | + * - An external monitoring tool via webhook |
| 92 | + * |
| 93 | + * QUESTIONS TO CONSIDER: |
| 94 | + * ---------------------- |
| 95 | + * 1. Should getPosition() reflect backpressure? (Probably not - your position |
| 96 | + * in line doesn't change, just how fast the line moves) |
| 97 | + * |
| 98 | + * 2. What about pop()? Should it also respect backpressure or just peek()? |
| 99 | + * (Usually just peek - once you're peeked/selected, you should be admitted) |
| 100 | + * |
| 101 | + * 3. Should there be a "circuit breaker" mode where health < X completely |
| 102 | + * stops admission vs gradual degradation? |
| 103 | + * |
| 104 | + * 4. How do you prevent oscillation? (Health drops -> fewer users -> health |
| 105 | + * recovers -> flood of users -> health drops again) |
| 106 | + * Consider: smoothing/averaging, hysteresis, ramp-up delays |
| 107 | + */ |
| 108 | +class BackpressureQueue implements QueueInterface |
| 109 | +{ |
| 110 | + public function __construct( |
| 111 | + private QueueInterface $inner, |
| 112 | + private HealthCheckerInterface $healthChecker, |
| 113 | + private float $minHealthToAdmit = 0.2, |
| 114 | + ) {} |
| 115 | + |
| 116 | + // Your implementation here |
| 117 | + public function add(string $identifier, int $priority = 0): int |
| 118 | + { |
| 119 | + return $this->inner->add($identifier, $priority); |
| 120 | + } |
| 121 | + |
| 122 | + public function remove(string $identifier): void |
| 123 | + { |
| 124 | + $this->inner->remove($identifier); |
| 125 | + } |
| 126 | + |
| 127 | + public function peek(): ?string |
| 128 | + { |
| 129 | + $score = $this->healthChecker->getScore(); |
| 130 | + |
| 131 | + if ($score < $this->minHealthToAdmit) { |
| 132 | + return null; |
| 133 | + } |
| 134 | + |
| 135 | + return $this->inner->peek(); |
| 136 | + } |
| 137 | + |
| 138 | + public function getPosition(string $identifier): ?int |
| 139 | + { |
| 140 | + return $this->inner->getPosition($identifier); |
| 141 | + } |
| 142 | +} |
0 commit comments