Orion
15:02 UTC. Kickoff. The odds move. Bets flood in. Cash‑out lights up. Your risk engine hums. You watch p99 climb. You have ten minutes to save the half.
When we say high‑throughput, we mean hard load and tight tails. Think tens of thousands of bets per minute, in short bursts, with fans hitting the same market at once. The mean is not your friend. The tail is. For why, see tail latency at scale.
In betting, bursts have a shape. A price change fans out to many users. In‑play events hit cash‑out. Each bet may call risk, balance, KYC, fraud, and sometimes a trader override. All in the hot path. Each copy, queue, and cache miss adds jitter. That is what breaks the user’s trust.
You do not pick “cloud” or “metal” in a vacuum. You pick based on five limits: your latency budget, your team skill, money over time, where you must keep data, and how fast you ship new markets.
Direct answer if you need it now: If you must keep in‑play p99 under 10–15 ms at 5–10k TPS and you can place boxes near venues, bare metal tends to win for steady tails. If you add regions often and want managed data, and can accept slightly higher tails, cloud or a split model ships faster and costs less early.
Let’s open the latency budget. A packet lands on a NIC. An interrupt fires. The kernel moves bytes to user space. Your service reads, checks cache, maybe calls a DB, calls pricing and risk, then sends a response. Each hop can add jitter. Network path design helps; learn how Anycast routing and network paths work. Two quick wins: pin hot threads to fixed cores; keep hot keys in memory, not across zones.
What cloud gets right: elastic scale, managed stores, fast global reach, paved IAM, and a big toolbox. It also hides a lot of toil. But you can hit “noisy neighbors,” high egress bills, micro‑bursts that warm slow, and wider p999s. The AWS Well-Architected reliability practices show good patterns, but you still own tails.
What metal gets right: steady timing. You can use DPDK kernel bypass, NUMA pinning, huge pages, and PTP time. You place boxes in colo near feeds and payment rails. You also take on ops work: spares, PDU, patching, on‑call for parts, and change control. It is power with a tax.
The game is often won in the network lane. Colo, peering, and cross‑connects can chop hops and jitter. If you get a cage close to venues or data vendors, you can shave ms off your path. See how financial services colocation is built for this.
Run a managed event log. Apache Kafka documentation will guide you. Keep intake stateless and autoscaled. Use in‑memory caches for hot odds and user balances. Keep fan‑out light; push deltas. Pin a few fixed nodes for the risk brain so it stays warm. Use SR‑IOV or accelerated NICs when you can.
In a cage, use FPGA or tuned C for feed handlers. Store hot reads in ClickHouse for real-time analytics. Keep quick keys in Redis latency patterns. Use DPDK/AF_XDP for intake. Lock hot threads to cores. Keep queues short. Use a small cloud edge to burst static web, auth, and CRM when needed.
Set SLOs that match the sport. Pre‑match can have a wider tail. In‑play cannot. Write them down. Track error budgets. The Google SRE book on SLOs shows how to set and hold the line.
Know your lanes. Payments touch PCI. See the PCI DSS overview. If you serve EU users, know GDPR data residency basics. If you serve the UK, read the UKGC Remote Technical Standards. These rules may push you to certain regions or to metal for strict data walls.
Buyers ask for proof. Be clear on audits. See What is SOC 2 and ISO/IEC 27001. Cloud gives you shared attestations. Metal gives you full control but more to prove. Plan for it early.
Watch the right things. Trace the hot path with high detail. Track rate, errors, and duration (RED). Sample smart under burst. Add profiles so you see where time goes. OpenTelemetry is a good base and lets you swap vendors later.
Do not trust list prices. In cloud, the bill can swing with burst, egress, and managed taxes. You need FinOps. Tag things. Set guardrails. Model worst case, not average. See core ideas in FinOps principles. On metal, capex is up front, but the curve is flat if you sweat boxes well.
Energy and brand matter too. Users, staff, and even partners ask about carbon. Track your mix. Pick regions or colos with clean grids. Tune for work per watt. The Green Software Foundation has simple moves that help.
Fast rule of thumb for a meeting: Need sub‑10 ms p99 for in‑play and you can get close to the venue? Lean metal for intake/pricing/risk, and keep customer‑facing parts in cloud. Need to enter three new countries this year and ship features weekly? Lean cloud for most, with a small metal core where tails hurt most.
Case note (composite): A mid‑size book kept intake, cash‑out math, and market move fan‑out on metal in a London colo. Customer web, CRM, and data science stayed in cloud. They used PTP and DPDK at the edge. Result: p99 for in‑play bet intake dropped from 14 ms to 7 ms at 8k RPS. Cash‑out stale events fell by ~35%. Fans feel this. Review sites track it, and users move. For neutral views and guides we watch, see más información.
Anti‑patterns to avoid: Blind lift‑and‑shift with no cache plan. One AZ “prod” with no drills. Under‑sized NAT or eBPF paths that cap throughput. Over‑sharded caches with hot keys split wrong. Shadow traffic that is not real (no fan‑out, no auth, no fraud calls). Egress you did not price. No SLOs, so no guardrails.
These are typical, not promises. Numbers vary by feed, code path, and network. Verify with a 90‑day spike.
| In‑play bet intake p99 at 5k TPS burst | 12–25 ms, wider p999 | 6–12 ms, tighter p999 | Depends on NIC, cache hit rate, and fan‑out size |
| Jitter under colo‑grade feeds | Higher; noisy neighbors possible | Lower; you control the stack | Kernel bypass and PTP help on metal |
| Warm capacity step time (5k → 25k RPS) | 1–5 min with autoscale and warm pools | Seconds if idle headroom exists | Keep headroom vs cost; pre‑warm on event days |
| Failover RTO (regional event) | 1–10 min with multi‑region patterns | 5–20 min unless you double‑run | Test failover often; people add minutes |
| Time sync method | NTP/Chrony by default | PTP + NIC HW timestamps | Better sync → fairer cash‑outs and audits |
| Kernel/network stack | eBPF, io_uring, SR‑IOV | DPDK/AF_XDP, IRQ pinning | Choose based on code path and team skill |
| Cache hit path | Managed Redis/Memcache | Self‑hosted Redis on NVMe/RAM | Hot keys and eviction policy drive tails |
| Analytics latency | BigQuery/managed ClickHouse: minutes→seconds | ClickHouse/kdb+ on boxes: sub‑second→seconds | ETL, merge windows, and cost per TB differ |
| Data egress exposure per TB | Medium to high, region dependent | Low; cross‑connect flat fees | Watch broker→DB and CDN fan‑out paths |
| Compliance posture | Shared attestations, fast starts | Bespoke audits, more control | Map scope early (PCI, GDPR, RTS) |
| Ops headcount (per ~1m MAU) | Lower, 3–6 SRE/infra | Higher, 6–12 with on‑site/remote | Depends on tooling and vendor support |
| Capex vs Opex bias (3‑year TCO) | Opex heavy; flexible | Capex heavy; flat unit cost | Include HW refresh and power |
| New market lead time | Weeks (legal + deploy) | Months (colo + contracts) | Colo and network cross‑connects take time |
| DDoS surface and mitigations | Managed edge, strong defaults | Needs vendor plus your design | Mix anycast/CDN and L4/L7 filters |
| Vendor lock‑in risk | Higher unless you plan exits | Lower at infra; higher at HW vendors | Abstraction adds latency; choose wisely |
Run a spike. Two paths, in parallel. Cloud path: build intake, cache, risk calls, and fan‑out with managed parts. Metal path: a small colo setup with tuned NICs and kernel bypass. Feed both the same shadow traffic. Run chaos. Kill nodes. Kill links. Hold p99 and p999 to the same SLO. Use hard exit rules. Read the core ideas in Principles of Chaos Engineering.
Time sync is not nice to have. It is core to fair cash‑out and dispute logs. Use PTP where you can. Use boundary clocks. Prefer NIC HW time stamps. Holdover matters if GPS drops. For a primer, see NIST on precision time synchronization.
Most winners do a hybrid. They put the work that must not blink on tuned metal near feeds and payment rails. They keep the fast‑moving product and growth work in cloud. They measure, not guess. They run drills on big match days. They keep a small ops tax where it pays for lower tails. They spend the rest where fans feel it: fast markets, clean cash‑outs, no drama at deposit or withdraw.
Start at the NIC. Set RSS queues. Pin IRQs to fixed cores. Turn off irqbalance for the hot path. Use huge pages. Isolate CPU sets for intake threads. Prefer AF_XDP or DPDK for packets. Keep caches in RAM. Use read‑aware data layouts. Cut copies: zero‑copy where you can. Avoid cross‑zone calls in the hot path. Keep queues short; prefer backpressure near the edge. Profile often. Trim until the p999 moves.
Map scope. Keep PCI in small boxes. Tokenize PANs. Keep PII in regions per law. Log with care. Build export tools for SARs. For UKGC RTS, keep transaction logs, uptime proof, and RNG/cash‑out fairness tests. Cloud helps with quick attestations. Metal helps with hard walls. Either way, design for audits from day one.
Trace every hot path call. Propagate IDs across intake, cache, risk, balance, and response. Keep RED metrics and a few business KPIs: bet accept rate, cash‑out stale rate, market update lag. Alert on p99 and p999, not on CPU. Build a one‑page war board for match days. Run game day drills every month.
Pick small, strong teams for the hot path. Give them a budget and clear SLOs. Let them say “no” when a feature hurts tails. Write runbooks. Practice failovers. Pay down tech debt that adds jitter. It is cheaper than a PR crisis at derby time.
Editorial note: Last technical review: Aug 2026. This article shares field patterns and public sources. It is not legal advice. Please follow local laws and responsible gambling rules.