Delivered for a multi-tenant tote and fixed-odds platform we built and operate, through Platform to Platform, Data to Data and 24×7 Operations Desk.
The challenge. An operator wanting to launch a wagering brand needs racing content from several providers, a wallet, a tote and fixed-odds bet path, an agent hierarchy and a settlement model — and does not want to run its own stack to get them.
Context
Ashva is a multi-tenant tote and fixed-odds wagering platform we designed and built from 2020, and still work on daily.
Its technology was acquired in February 2025 by BetMakers Technology Group Ltd (ASX: BET), whose announcement describes what it bought from Protocol Zone Private Limited as “digital tote technology, API data feeds, proprietary trading and ratings models”. That technology became the GTX platform, which serves international ADW and tote wagering customers.
GTX went live on 11 August 2025, with Greyhound Racing Ireland as first customer, running on Google Cloud Platform. We continue to develop, deploy and operate it as technical partner.
Both statements above are theirs, not ours: acquisition · go-live.
The platform is tote-led: tote and pari-mutuel is where the volume goes. Fixed odds runs alongside on the same engine and matters, but the tote path is where the harder engineering sits.
The problem
An operator that wants to run a racing book has to assemble five things before it can take a single bet: normalised racing content, a wallet that holds real money, a path for the bet to reach a pool or a price, a way to pay agents and affiliates, and a settlement model. Each one is a project. Together they are a platform, and a platform is not what the operator is trying to build.
The usual answer is a white-label deployment per operator. That answer is expensive in a specific way. Racing peaks are synchronised — a Saturday metropolitan meeting is a Saturday metropolitan meeting for every brand at once — so per-tenant infrastructure has to be provisioned for peak, per tenant, for a peak that arrives simultaneously. Capacity sits idle and cost scales with brand count.
Why the tote side is the hard part
In fixed odds the operator holds a position and the engineering problem is risk. On the tote path the platform does not compute the dividend — the external host it routes to does. That sounds easier and is not. It converts the problem into deciding, per bet and before the jump, whether the bet and its risk should leave the platform at all, and then being able to reproduce a settlement the platform did not calculate.
The deadline is the jump. Before it, prices and liability move continuously; scratchings arrive mid-market and have to propagate to displayed prices, to bets already accepted, and to the routing decision itself, while the market is still live. Exotic and multi-leg bet types compound this because a single leg changing affects every combination that touches it.
Multiply that by tenants on shared infrastructure, each with its own betting rules and its own routing policy, and the isolation question stops being architectural taste.
What we built
Data-level tenant isolation on one deployment. Tenant identity is enforced at the data layer rather than applied by convention in application code. Each tenant carries its own branding, UI layout, wallet integration and betting rules. They share the engine.
Helm-based tenant onboarding. A new tenant is a chart, not a build. That is what makes minutes possible for the deployment step. Configuration, content provider agreements and payment onboarding are still measured in weeks, and we say so rather than implying a tenant is trading the same afternoon.
Racing content aggregation and normalisation. Multiple racing data providers, each with its own model, feed one internal structure covering pre-race fields, live prices, market changes, scratchings, post-race data and results. Providers disagree about identifiers, field formats and timing; normalisation is where that disagreement gets resolved once instead of in every downstream component.
A bet-routing engine with four outcomes. Per tenant, per market, a bet can be bypassed to an external tote host, bypassed to a fixed-odds operator, retained in-house and settled against the operator’s own book, or split under a dynamic risk-sharing rule. The two bypass paths are separate policies, not one: they go to different hosts, on different protocols, with different commission and settlement behaviour. Routing is a business-rules decision at bet time, not a deployment-time choice, because the correct answer differs by pool, by liability and by tenant.
Multi-currency wallets. Deposits, withdrawals and settlement in the tenant’s currency, with exchange-rate configuration, alongside multi-language and timezone handling so a tenant in one country can offer racing from another without its punters doing arithmetic.
Agent and sub-agent hierarchies. Multi-layered agent networks with commission structures, revenue-share and liability visible at each level, and per-agent limits, settlement cycles and controls. This is unglamorous and it is frequently the reason a platform gets chosen or rejected.
Autoscaling and self-monitoring. Kubernetes with fault-tolerant services and autoscaling for the synchronised peak. Prometheus and Grafana plus purpose-built notifier scripts for alerting, so the platform reports its own trouble rather than waiting for an operator to notice. Elasticsearch indexes bet flow and punter behaviour for real-time tracking and operator reporting.
Stack: Core Java and Python on the back end, ReactJS and React Native with TypeScript on the front, ScyllaDB and MySQL for storage, Kafka for streaming, Elasticsearch for search and analytics, Kubernetes, Helm and Docker for deployment.
Results
Infrastructure cost fell substantially against a per-tenant baseline. One deployment absorbs the synchronised peak instead of every tenant provisioning for it separately. This is the strongest commercial argument for the architecture and it is a consolidation argument, not a feature.
Tenant deployment is measured in minutes because it is a Helm operation.
Operational cost fell with a single management surface. Configuration changes, market suspensions and releases are one operation rather than one per tenant, which also removes the drift that comes from applying the same change N times by hand.
Operational reporting is consolidated. Live money in, exposure and position across tenants in one place rather than reconciled per tenant overnight.
We have no throughput, latency or uptime figures cleared for publication, so there are none here.
What we would do differently
Two things.
Tenant isolation at the data layer was retrofitted in places rather than assumed from the first commit. Every layer that touches money or liability has to be tenant-aware, and the cost of discovering one that is not is a migration under load. We now build multi-tenant from the start, including on client work where the client insists they will only ever have one tenant.
Provider normalisation was initially treated as an adapter problem and it is a data-modelling problem. The internal racing model is the asset; the adapters are disposable. Getting that order wrong means each new provider costs about as much as the first.
Where this transfers
Nothing in the architecture is specific to racing. Many tenants on shared infrastructure, isolation enforced rather than assumed, one operational console instead of N, and a routing decision made per transaction against business rules is the same shape as multi-tenant payments, franchise and retail estates, insurance distribution through brokers, and any commission-bearing agent network.