Live sports data, across a publishing group.
A system ingests sports data from an external feed, normalizes it and distributes updates to a publishing group’s portals. Each publication keeps its own identity.
The problem to solve.
Results, standings and statistics arrive as files from an external provider. They need to become consistent records, available during events and usable by publications with different presentation needs.
Keep the source. Separate the presentation.
Original files are stored before parsing. A scheduled job, a normalized database and one API sit above them. Widgets share their logic while each publication controls the visual style.
If parsing fails, the source data remains available. Update frequency depends on the feed and the scheduled job.
Inside the system.
Import via FTP
The system retrieves the sports data provider’s published files over FTP.
Source files retained
Every source file is retained before processing, so the original input remains available if parsing fails.
Scheduled processing
A scheduled job reads the files, extracts the records, and normalizes them into a single schema.
Results database
Standings, results, and statistics are stored as queryable records rather than scattered files.
Results API
The API exposes the latest normalized data while events are underway.
Widgets in the portals
A library of customizable components lets each publication apply its own colors and visual style.
What it enables.
The same backend supplies multiple portals. Results, standings and statistics can be queried through a normalized source.
Publications adapt widgets to their own identity without duplicating the implementation. The architecture is designed for live-event traffic spikes.