Part of the Ashva module inventory — a multi-tenant tote and fixed-odds betting platform we built and operate. The engineering practice behind it is our platform build and integration service line.
A wagering platform is mostly a boundary. Racing data, tote pools, results and third-party prices come in; prices, market state, settlement and reporting go out. Almost every incident that looks like a platform failure starts as a feed that changed shape, arrived late, or arrived twice.
This module owns both boundaries and treats them the same way.
Land it raw, then transform
Inbound payloads are stored as received before any transformation. When a provider quietly renames a field or starts sending an empty element where it previously sent a value, the raw record is the difference between a ten-minute diagnosis and a day of speculation.
Validate at the edge
Every inbound stream declares a schema and is validated against it at the boundary. Failures are quarantined and alerted rather than partially applied. A half-processed field update is the worst available outcome: it leaves markets live against a state nobody intended.
Replay is a design requirement
Providers re-issue files. Outages create gaps. Corrections arrive after settlement. Streams can be re-run from a stored position, and the effect of a replay downstream is traceable, so reprocessing a day of results is an operation rather than a project.
Outbound contracts are owned per consumer
Aggregators, downstream operators and reporting destinations each consume a versioned contract. Publishing one shape to everyone means every consumer upgrades on the same day, which in practice means nobody upgrades.
Failures stop, they do not disappear
Messages that cannot be delivered are held with the reason and retried under policy. Retry limits, back-off and alert thresholds are configured per interface and monitored by the Operations Desk.
What this module does not do
It does not interpret the data. Meaning is assigned by the modules that consume it: the schedule, the statistics and the odds module. This layer is responsible for getting it across the boundary with validation, ordering rules and duplicate handling defined for each integration.