Le scommesse a evento in corso sono la parte tecnicamente più esigente di uno sportsbook. Le quote vengono ricalcolate di continuo e la decisione di accettare una giocata si prende in frazioni di secondo. La difficoltà non sta nell'interfaccia: l'operatore vede sempre l'evento con un ritardo rispetto a ciò che sul campo è già accaduto.

La catena dei dati e i suoi ritardi

Tra l'azione sul campo e lo schermo del giocatore si interpongono più anelli: rilevazione dell'evento sul posto, trasmissione al sistema del fornitore di dati, normalizzazione, ricalcolo delle quote da parte della piattaforma di trading, consegna al client. Ogni anello aggiunge il proprio ritardo e lo scarto finale è la loro somma. Un problema a parte è lo streaming: di norma viaggia con un ritardo proprio, che non coincide con quello dei dati.

Come l'operatore compensa lo scarto

Il ritardo non è eliminabile del tutto, perciò il rischio si contiene per via procedurale:

  • ritardo di accettazione — la giocata è confermata dopo una breve pausa, non all'istante;
  • sospensione dei mercati nelle fasi pericolose e in caso di perdita del segnale;
  • riscontro tra le fonti — una divergenza tra i feed blocca il trading sull'evento;
  • limiti ridotti sui mercati in cui il prezzo si muove più in fretta.

Che cosa richiede alla piattaforma

Il carico si distribuisce in modo estremamente irregolare: i picchi di richieste cadono nei momenti chiave della partita, proprio quando l'intero albero dei mercati viene riprezzato. L'accettazione della giocata deve essere idempotente, altrimenti un reinvio alla caduta della rete mobile genera un duplicato; e un rifiuto deve restituire una motivazione comprensibile, non un errore generico.

La qualità dell'offerta live si misura quindi su caratteristiche ingegneristiche — tenuta dei feed e prevedibilità delle latenze — e non sull'ampiezza del palinsesto.