PATTERN Cited by 1 source
Two-stage match-then-deliver pipeline¶
Pattern¶
Split event processing into two physically separate stages with a queue between them:
-
Matching stage (CPU-bound) — evaluates which subscribers care about each event. Working set is dominated by subscription caches. Wants fast cache access and enough cores to evaluate criteria at line rate.
-
Delivery stage (network-bound) — dispatches matched events to recipients. Working set is dominated by in-flight requests and concurrency budget. Wants generous concurrency to absorb tail latency without head-of-line blocking.
The queue between stages is the contract — it provides:
- Independent scaling — each stage autoscales on depth of its feeding queue.
- Flow control as first-class signal — delivery pods hold permits per in-flight delivery, releasing on completion. Slow deliveries throttle pull rate naturally; queue depth rises; autoscaling adds capacity.
- Contained blast radius — slow recipients stay a delivery-side concern. Matching keeps producing; the webhooks queue absorbs. Impact is bounded to traffic destined for the affected recipient.
- Clean ownership boundary — new code goes into matching if it's about "who gets this event" and into delivery if it's about "how to get it there."
Why not a single combined process?¶
Combining matching and delivery forces every worker to carry both CPU resources (subscription caches, evaluation cores) and network resources (connection pools, file descriptors, concurrency budget). A single slow recipient stalls the matching loop behind it — a failure mode Atlassian explicitly migrated away from (Source: sources/2026-07-29-atlassian-inside-the-events-rail).
Applicability¶
Use when: - The decision layer (who cares?) and the dispatch layer (deliver it) have fundamentally different resource profiles - You need flow control between decision and dispatch - Slow/unreliable downstream recipients must not affect decision throughput
Seen in¶
- sources/2026-07-29-atlassian-inside-the-events-rail — Events Rail: Event Matching (tens of thousands eval/sec) → Webhooks Queue → Event Delivery (hundreds of concurrent outbound HTTP)