Live-event prediction platform with sponsor-funded rewards and automated scoring

Audiences follow scheduled live events passively, with engagement high for a few hours and near zero either side of it, while the sponsors underwriting those events have no direct relationship with the people watching. Everything the product needed — schedules, participants, groupings, live results — came from a single third-party data provider under a strict per-minute rate limit, and raw measurement data isn't a result: the product needed a decision about who was best at a given point, computed correctly, because it determined who won a reward.

Took data ingestion off the request path entirely, building four standalone workers at different cadences — a one-off catalogue backfill, a daily statistics refresh, a pre-event group builder, and a live in-event worker — so the user-facing API never blocks on the third party and an outage degrades data freshness rather than availability. Every worker checks for existence before writing, and the live worker rewrites a segment's data wholesale rather than reconciling differences, so any run is safe to repeat after a partial failure — the correct property when a live third-party feed will fail mid-event.

Pacing between provider calls is built into the pipeline's structure rather than bolted on afterward, so a full refresh spanning many endpoints stays inside the provider's quota. The reduction from raw measurement data to a resolved outcome happens once, inside the ingestion worker, so the application, the rankings and the reward all read the same settled result rather than each deriving their own.

A card's lifecycle status — selected, ready, in progress, played — is computed from the event calendar at query time instead of stored, so nothing has to sweep the table and it can't drift out of sync. For the API itself, an ORM is used where the mapping genuinely helps — identity and roles — and parameterised raw SQL for the composite reads that assemble an event, its venue, its participants and the user's own picks into one response — a meaningful saving for a client on mobile connectivity.

A passive audience gained something to do: card creation happens days ahead, picks happen in a defined window, results resolve live, and rankings persist afterwards — four separate reasons to open the app across an event's calendar. Outcomes resolve automatically with no operator watching an event to score it, and because ingestion is isolated and every job is safe to repeat, a third-party failure during a live event became a recoverable data-freshness issue rather than an outage. Sponsors gained a direct channel to the audience built into the navigation and the reward itself, and because rewards are fulfilled physically with no payment functionality in the product, it carries no payment-processing risk at all.

Something holding you back?

New build, rebuild, or adding AI to what you already have — I'll take a look and give you an honest perspective.