Route each drop alert to the right channel

A drop alert relay does not have to send everything to one place. Between the threshold filter and the webhook sits a routing table: a small map from sport and severity to a channel, so soccer drops land with the soccer readers and only the biggest moves page the urgent channel. One process, one stream, many destinations.

Where the router sits

The order matters: filter first, dedupe second, route third, send last. Filtering drops the alerts you never wanted. Deduplication, with the keys and cooldowns from the dedupe guide, collapses repeats of the same falling price. Only then does routing decide where the survivor goes, and a per-channel queue hands it to the webhook worker.

That last hop deserves its own queue per destination. The relay guide already keeps the webhook POST off the reading loop; with several channels, the same rule applies per channel, so one throttled destination cannot delay the rest.

Route by sport first

The alert carries sport and league in plain fields, which is all a router needs. Most readers want a channel per sport they follow, not a feed of everything:

ROUTES = {
    ("Soccer", "normal"): SOCCER_WEBHOOK,
    ("Tennis", "normal"): TENNIS_WEBHOOK,
}
DEFAULT = GENERAL_WEBHOOK

def pick_webhook(alert, level):
    return ROUTES.get((alert["sport"], level), DEFAULT)

League-level routing works the same way when a channel cares about one competition. Keep the table small: every row is a promise that someone reads what lands there.

Then by severity

The second axis is how big the move was. The stream sends prices, so the relay works out the percentage itself: the fall divided by the old price, as the drop alerts guide documents. Two tiers are enough for most setups: everything at or above your threshold goes to the normal channel, and a second, higher bar, say 8% where 5% is the floor, also mirrors to an urgent channel that fewer people follow more closely.

Resist finer tiers. Three buckets per sport is a routing table nobody reads, and a drop large enough to matter reads clearly at two levels.

Respect each channel's pace

Every webhook has its own posting limit, and the platforms answer a burst with a 429 and a Retry-After header of their own, as the relay guide's retry rules cover. With per-channel queues, honoring that header pauses only the channel that sent it. The chat platforms' limits, not the stream, set your posting ceiling on a busy slate.

Two settings from the relay guide absorb most bursts before routing even matters: post one message per event instead of one per outcome, and hold a cooldown per selection so a price that keeps falling does not post every few seconds.

Measure the routing itself

Log the route each alert took, not just the send. A weekly count per channel tells you which rows of the table earn their place: a channel that receives forty alerts a day and gets read twice is a filter problem, not a routing success. Move its threshold up or merge it back into the general channel.

Filter, dedupe, route, send. The stream delivers the moves; the table decides who hears about them.