Dati sportivi live, su più testate.
Un sistema raccoglie dati sportivi da un feed esterno, li normalizza e distribuisce gli aggiornamenti ai portali di un gruppo editoriale. Ogni testata mantiene la propria identità.
Il problema da risolvere.
Risultati, classifiche e statistiche arrivano come file da un fornitore esterno. Devono diventare dati coerenti, disponibili durante gli eventi e utilizzabili da testate con esigenze grafiche diverse.
Conservare la fonte. Separare la presentazione.
I file originali vengono salvati prima del parsing. Sopra di essi lavorano un job periodico, un database normalizzato e una sola API. I widget condividono la logica, mentre ogni testata cambia il proprio stile.
Se il parsing fallisce, il dato sorgente resta disponibile. La frequenza degli aggiornamenti dipende dal feed e dal job periodico.
Dentro il sistema.
Importazione via FTP
Il sistema recupera via FTP i file pubblicati dal fornitore di dati sportivi.
I file restano
Ogni file viene salvato prima del parsing, così il dato originale resta disponibile anche se l’elaborazione fallisce.
Elaborazione periodica
Un job periodico legge i file, estrae le informazioni e le normalizza in un unico schema.
Database dei risultati
Classifiche, risultati e statistiche vengono salvati come dati interrogabili.
API dei risultati
L’API rende disponibili gli ultimi dati normalizzati mentre gli eventi sono in corso.
Widget nei portali
Una libreria di componenti personalizzabili: ogni testata li integra con i suoi colori e il suo stile.
Cosa abilita.
Lo stesso backend alimenta più portali. Risultati, classifiche e statistiche sono interrogabili attraverso una fonte normalizzata.
Le testate adattano i widget alla propria identità senza duplicarne l’implementazione. L’architettura è progettata per i picchi degli eventi live.