DEDUPLICAÇÃO E COOLDOWNS
Deduplicando alertas de queda da Pinnacle.
Um único preço em queda pode gerar vários alertas da API de odds da Pinnacle: o motor reporta cada queda que cruza seu limite, mercados ao vivo se movem a cada poucos segundos, e um reinício pode entregar um lote que você já tinha tratado. Três chaves, uma regra de cooldown e um pequeno armazenamento de estado transformam isso em um alerta por decisão.
Por que uma seleção alerta mais de uma vez
O stream envia toda queda igual ou acima de min_drop dentro da sua própria janela de detecção. Um preço da casa que vai a 2.10, depois 1.98, depois 1.87 em vinte minutos cruza 5% duas vezes a partir de dois pontos de partida diferentes, e os dois cruzamentos são reais. Durante o jogo, a mesma seleção pode reprecificar a cada ponto de uma partida de tênis, então uma regra de 5% dispara de novo e de novo enquanto o favorito abre vantagem no set.
Reinícios acrescentam uma terceira fonte. Se o seu processo grava a posição antes de terminar de tratar um lote, os alertas desse lote são tratados de novo quando ele volta. A correção é de ordem, não de filtro: marque um alerta como concluído só depois que a mensagem que depende dele tiver saído.
Três chaves, três perguntas
Cada chave responde a uma pergunta diferente, e um relay normalmente precisa das três.
- A chave do alerta é o campo
id. Dois alertas com o mesmo id são o mesmo alerta; guarde por um dia os ids que já tratou e pule as repetições. Isso resolve exatamente o caso do reinício. - A chave da seleção é a partida mais o mercado mais o lado:
home,away,league,sect,outcomee o período, quando o mercado tem um. Dois alertas com a mesma chave de seleção descrevem o mesmo preço caindo ainda mais. É sobre essa chave que o cooldown roda. - A chave do evento é só a partida. Use-a quando uma mensagem por partida basta, para um canal que quer saber quais jogos estão se movendo, e não qual lado.
A regra do cooldown
Depois que um alerta de uma seleção sai, ignore os alertas seguintes dessa seleção até que um cooldown termine ou o preço tenha caído mais um limite inteiro em relação ao preço que você reportou por último, o que vier primeiro. A segunda cláusula importa: um cooldown sozinho esconderia um desabamento de 2.10 para 1.70 atrás de uma mensagem de 2.10 para 1.98 enviada um minuto antes.
state[key] = {last_price, alerted_at}
on alert for key:
seen = state.get(key)
if seen is None: send; store; return
fresh = now - seen.alerted_at < COOLDOWN
further = (seen.last_price - to_price)
/ seen.last_price >= MIN_DROP
if fresh and not further: return
send; storeDez minutos servem para mercados pré-jogo, onde uma linha deriva ao longo de uma tarde. Sessenta segundos servem para mercados ao vivo, onde a mesma regra engoliria um set inteiro de tênis. Rode ao vivo e pré-jogo com valores separados, já que eles chegam por streams separados de qualquer forma. Para ver o que uma porcentagem significa em termos de probabilidade antes de escolher um limite, a calculadora de odds em queda no pnclDATA transforma qualquer par de preços na mudança que o mercado fez.
Um armazenamento que sobrevive a reinícios
O estado é minúsculo: um pequeno registro por seleção sobre a qual você já alertou, e um conjunto de ids de alerta. Redis com expiração de 24 horas serve, e uma tabela SQLite com uma coluna expires_at varrida uma vez por hora também. Carregue-o na inicialização antes de abrir o stream, para que os primeiros alertas depois de um reinício sejam julgados contra as mensagens de ontem e não contra uma memória em branco. Uma grade pré-jogo em um dia cheio produz alguns milhares de seleções, muito abaixo de qualquer coisa que precise de ajuste.
Agrupando o que chega junto
Os alertas chegam em listas, e um evento costuma aparecer com dois ou três resultados na mesma lista quando um mercado reprecifica por inteiro. Agrupe pela chave do evento dentro de cada lote e envie uma mensagem que liste cada lado que se moveu. Entre lotes, um buffer de cinco segundos recolhe os retardatários sem atrasar ninguém de forma perceptível. O lado da entrega, incluindo o que as plataformas de chat fazem quando você posta rápido demais, está na página do relay por webhook.
Meça o efeito
Conte os alertas lidos e os alertas enviados, por stream, por dia. Um relay que envia um quinto do que lê está se comportando; um que envia quase tudo tem um cooldown que nunca pega, e um que envia quase nada tem um limite alto demais para os esportes que acompanha. Registre as duas contagens uma vez por hora e as configurações certas aparecem em uma semana.
Perguntas que esta regra levanta
O stream deduplica alguma coisa por conta própria?
Ele não repete um alerta com o mesmo id, mas cada novo cruzamento do limite é um alerta novo com um id novo. A deduplicação por seleção é tarefa sua.
E os preços que sobem?
O stream de quedas só reporta quedas. Uma seleção cujo preço volta a subir depois de uma queda não faz barulho; se você precisa das duas direções, consulte o mercado por REST ou receba os frames brutos do WebSocket.
O cooldown deve ser por esporte?
Por fase primeiro, por esporte depois. Ao vivo e pré-jogo diferem muito mais do que tênis e futebol. Comece com um valor para ao vivo e um para pré-jogo, depois ajuste um esporte só quando o log dele mostrar um problema.
O comportamento do stream segue a documentação publicada pelo fornecedor, conferida em 26 de setembro de 2026. Publicado em .