Limit Event Response is the response-side sibling of Manage Event Arrival. When you cannot control how fast events arrive, you control how fast you respond to them: process up to a fixed maximum rate, and hold or shed the rest.
A bounded queue absorbs short bursts while a rate limiter drains it at the set rate. Processing stays predictable under overload — at the cost of latency for queued events, or loss when the queue overflows.
How It Works
- Set a maximum response rate the handler can sustain without degrading.
- Buffer arriving events in a bounded queue ahead of the handler.
- Drain the queue at the set rate so events wait their turn, not overwhelm the handler.
- When the queue fills, apply a policy: shed lowest-priority events, drop the newest, or back-pressure the source.
Failure Modes
- A response rate set above sustainable capacity defeats the tactic — the handler still degrades under load.
- An oversized queue hides overload and inflates latency until events time out.
- A blind drop policy sheds critical events alongside disposable ones.
Verification
- Drive arrivals at 2–3× the response rate; confirm throughput holds at the set rate and latency stays within target.
- Fill the queue and assert the overflow policy fires as configured — shed, drop, or back-pressure — with no silent loss.
- Monitor queue depth and shed count in production; sustained growth signals an under-provisioned rate.
Variants and Related Tactics
- Manage Event Arrival caps the inflow at the source instead of the response — use it when sources are contractable.
- Rate Limiting (Throttling) places the same cap at an intermediary, per client.
- Bound Queue Sizes fixes the buffer so shedding decisions stay explicit.
References
- Software Architecture in Practice — Bass, Clements & Kazman (full citation)