Live in-play betting now represents the majority of handle for most sportsbooks in mature markets. The technical demands of supporting that product are fundamentally different from pre-match.

You’re ingesting odds feeds from providers like Sportradar, Betgenius (Genius Sports), or proprietary feeds, processing market updates that arrive in sub-second intervals during live events, and pushing those updates to a front-end that needs to render them without perceived lag. The pipeline from feed ingestion to player-facing display needs to operate within a latency budget that realistically sits under 500ms for the experience to feel “live.”

The architectural challenge isn’t just speed. It’s consistency under load. During a Premier League Saturday afternoon or a World Cup knockout stage, the volume of market updates multiplies. If your platform processes these synchronously, or if your odds management layer is tightly coupled to your settlement engine, a spike in one area cascades into degradation elsewhere.

Risk management ties directly into this pipeline. Automated liability limits, odds suspension triggers, and trader alert systems all need to consume the same real-time data stream. If your risk engine operates on a separate data path with its own latency characteristics, you get mismatches: a player places a bet at odds that your trader would have suspended two seconds ago. Those two seconds cost money.

The honest reality is that most operators don’t build their own odds compilation from scratch. They take a managed trading service or a data feed and apply their own margin models on top. The technical evaluation question isn’t “who has the best odds” but rather: how much control does the platform give you over margin configuration, market suspension rules, and liability management at the individual event, sport, and competition level? If the answer is “you can adjust overall margin percentage,” that’s a platform designed for operators who don’t want to compete on trading.

Features get the attention. Non-functional requirements determine whether the platform survives contact with reality.

Scalability in a sportsbook context isn’t a smooth, linear growth curve. It’s extreme spikiness. Your platform might handle 5,000 concurrent users on a Tuesday evening and need to handle 200,000 during a major event. The question for any vendor or architecture is: can you scale horizontally, and how quickly?

Microservices architectures allow you to scale individual components independently. Your bet placement service can scale separately from your account management service. A monolithic backend forces you to scale everything together, which means you’re either over-provisioned (expensive) or under-provisioned during peaks (broken).

But microservices aren’t free. They introduce distributed system complexity: service discovery, inter-service communication patterns, distributed transaction management, observability overhead. A poorly implemented microservices architecture is worse than a well-built monolith. The right question isn’t “is it microservices?” but “can the trading and bet placement paths scale independently from lower-throughput services like registration and KYC?”

Security requirements in regulated gambling go well beyond standard web application security. You need encryption at rest and in transit for all player data. You need audit trails that are immutable and available for regulatory inspection. You need DDoS mitigation that doesn’t add latency to the betting experience. You need penetration testing cycles that align with your licensing conditions.

PCI DSS compliance applies if you’re handling card data directly. GDPR applies to all player data in European jurisdictions. The architectural implication is that player data storage, access controls, and data retention policies need to be designed in from the start, not bolted on after a compliance audit flags issues.

Regulatory compliance is an engineering problem that happens to have legal consequences.

UKGC licence conditions now include specific requirements around customer interaction, affordability checks, marketing restrictions, and self-exclusion. These aren’t policies you paste into a terms page. They’re workflows that your platform must enforce programmatically. When the UKGC requires that a customer who hits a net loss threshold receives an interaction within a specific timeframe, your platform needs real-time loss tracking per player, configurable thresholds, automated trigger events, and auditable records of the interaction.

MGA requirements differ in specifics but share the structural demand: the platform must enforce jurisdiction-specific rules at the code level. If you operate across multiple jurisdictions, you need a configuration layer that can apply different rules per jurisdiction without forking your codebase. Multi-tenancy at the regulatory level, not just the branding level.

Geo-location verification is table stakes in US state-regulated markets. The platform needs to integrate with approved geo-location providers (GeoComply is the standard in most US states), verify player location at login and periodically during sessions, and block bet placement if verification fails. This isn’t a feature you add later. It’s a core platform concern that touches authentication, session management, and the bet placement flow.

Self-exclusion systems (GAMSTOP in the UK, state-level registries in the US) require real-time integration. When a player self-excludes, the platform must immediately prevent login, void any open bonus eligibility, and in some jurisdictions, return any stakes from unsettled bets. If your platform architecture can’t handle this as a synchronous, cross-service operation, you have a compliance gap.

Audit trail requirements deserve specific attention. Regulators expect to see complete, timestamped records of every transaction, every odds change presented to a player at the point of bet placement, every responsible gambling interaction. If your architecture doesn’t capture this data in an immutable, queryable format, you’re building a regulatory risk that compounds over time.