How to build a horse racing odds comparison

Build the comparison around the race, not around bookmakers. That keeps the interface aligned to how users think: one race, many runners, many observed prices. A good internal model begins with the race identifier from the racecard feed, then attaches the runner list and any race metadata you want to display beside the grid, such as course, time and distance.

Once the race exists as the parent object, each runner becomes a row in the comparison table. The odds endpoint supplies raceId, horseId, bookmaker, bookmakerId, price and eachWay, so your storage layer should be able to attach several price observations to one runner without overwriting earlier observations unless your refresh policy says otherwise.

The comparison should not be drawn directly from the raw feed. First, group all observations by horseId so every runner gets a single row with a price cluster beneath it. That lets you show the best available observed price, the contributing bookmakers, and any each-way variants without scattering the same runner across the page.

For a clean experience, derive the visible row from the grouped data rather than from the incoming order. If the feed returns several prices for a runner, sort them inside the runner group before display. A simple approach is to show the most useful price first, then the remaining observed prices in a secondary list or compact cell. That keeps the grid readable on mobile and desktop alike.

Bookmaker labels should be stable and human-readable, even when the raw feed uses a source-specific name or identifier. Use bookmakerId as the canonical key for deduplication, then render the bookmaker name exactly as your product design requires. This is particularly important when the same source name appears in different casing, abbreviations or punctuation styles.

If you want users to compare prices across sessions, the label must remain consistent over time. That means the label mapper should live in one shared layer rather than being redefined in each page component. The safest pattern is a single bookmaker dictionary keyed by bookmakerId, with a fallback to the provided bookmaker string when no mapped display name exists. This avoids accidental renaming that would make a snapshot look like a new source.

Odds comparison becomes unreliable when invalid or malformed prices are allowed into the grid. Keep a strict validation step before sorting. Your grid should only contain prices that can be displayed as observed values, and it should preserve the source price string exactly as returned by the feed. Do not rewrite the price into a synthetic format just to make the table look uniform.

After validation, sort the prices in a consistent way. You may choose alphabetical bookmaker order for browsing, or a price-first order if the goal is to surface the most competitive observation. The important part is consistency. If you sort by price, make sure the same rule is used in every refresh so the runner rows do not jump unnecessarily. If a runner has only one valid observed price, show that plainly rather than forcing the data through a comparison layout that implies more coverage than exists.

Users need to know when a price was observed, but timestamps only help if they are comparable across runners and refreshes. Store the feed timestamp at the snapshot level and, where available, keep per-observation timing metadata alongside the price. Then normalise all displayed times into one timezone and one format in the UI so a user can tell whether two runners were refreshed from the same snapshot or from different moments.

The key architectural point is separation: source time, stored time and display time should not be the same field. The source time is what the feed provided, the stored time is what your service records, and the display time is what the user sees. That separation makes it easier to compare updates within a race without mixing current data with earlier snapshots.

A shared snapshot is the simplest way to keep the odds table coherent for multiple users. Instead of refreshing each viewer independently, load one race snapshot, cache it briefly in your application layer, and let all viewers of that race read the same version until the next refresh cycle. That prevents one user seeing a half-updated grid while another sees the old one.

Because these prices are observed data rather than guaranteed real-time quotes, the snapshot should be treated as a current view of the feed, not as a permanent record. A sensible pattern is to refresh on demand and replace the previous race snapshot atomically. If the refresh fails, keep serving the last known good snapshot rather than emptying the grid. That keeps the user experience stable while preserving the last valid comparison.

A comparison screen works best when it answers three questions quickly: who is running, what prices are observed, and which source is represented by each price. Start with the runner name and then present bookmaker labels and prices in a compact, scan-friendly grid. If you have space, add a separate column for eachWay so users can distinguish straight win prices from each-way observations without reading into the wrong figure.

Keep the interface honest about completeness. If a runner has no valid price observations yet, say so clearly rather than leaving a blank cell that looks broken. If a bookmaker returns only one observed price, show it as a single entry; if several prices are present, collapse them under the runner row so the table remains manageable. The goal is not to maximise density, but to preserve a readable comparison.