1.9 KiB
1.9 KiB
Event Pressure Notes
This is a quick note on potential event-channel pressure in the current proxy architecture.
Why this matters
Proxy request handling currently emits events synchronously into a shared channel. If producers are faster than the consumer (TUI/event loop), the channel can fill and block producers. When that happens, request handling can stall even if upstream/downstream network paths are healthy.
Where pressure comes from
- Every request can produce multiple lifecycle events (
started,finished,failed, warnings). - CONNECT + MITM flow can emit both tunnel-level and inner-request events.
- Bursty traffic (many small requests, retries, connection churn) amplifies event rate quickly.
User-visible symptoms
- Request latency spikes that do not match upstream timings.
- Intermittent pauses during high traffic.
- Shutdown/restart feeling delayed when many events are in flight.
Current risk profile
- Channel buffer size helps absorb bursts, but only up to a point.
- Backpressure is currently coupled to request path execution, so stalls propagate into proxy behavior.
Mitigation options
- Introduce non-blocking event enqueue for low-priority events.
- Keep critical events blocking (fatal/start/stop), but drop or coalesce high-volume request events under load.
- Add an internal event relay.
- Proxy handlers write to a local buffered queue; a dedicated goroutine forwards to the main channel.
- Coalesce repetitive events.
- Aggregate similar warnings or per-interval request counters instead of per-request chatter.
- Add lightweight metrics.
- Track dropped/coalesced events and queue depth so pressure is visible during development.
Practical near-term suggestion
Start with a small event relay + drop policy for non-critical request events when queue depth is high. This contains proxy-path stalls without changing the external event model too much.