I am currently developing a multi-tenant commercial web application for Betfair customers.
Our backend architecture is designed to minimise server infrastructure overhead and betfair server usage. I am configuring our systems to use my Delayed App Key for development and connection testing, with the architecture built to swap to our Live Vendor Key once certified.
Before i finalise our live data layer, i want to ensure our data distribution model is fully compliant with the Betfair Vendor Program guidelines.
my Proposed Architecture (mental model):
- Market Metadata: my backend uses our Vendor credentials to pull listMarketCatalogue and cache event frameworks in MongoDB/Redis.
- Live Pricing (ESA): To avoid opening hundreds of separate TCP/WebSocket connections for every individual web customer (which would exhaust server resources and flood Betfair with redundant connection requests), we intend to use a centralized caching model.
- Data Flow: Our backend will open a minimal pool of Master Stream connections to the Betfair Exchange Stream API (ESA), authenticate the subscription via an active, logged-in customer's session token (ssoid), and stream the price deltas into a central Redis cache. Our web app will then broadcast those updates to our active users internally via lightweight WebSockets.
- Does Betfair permit this "Token-Pinned Master Stream" model where a shared backend stream is authenticated via an active user's ssoid to populate a localized cache for active users?
- If this is acceptable, does your team have a preferred best practice for seamlessly handling authentication handovers on an active stream when a user session expires?
- If this model violates data redistribution clauses, what is Betfair's recommended architectural pattern for scalable, multi-tenant web applications to consume the Stream API without triggering connection limits?