Real-time systems · B2C

Keeping a high-traffic, real-time product fast and stable while it keeps changing

A high-traffic consumer product with continuous live data, a catalogue of 900+ titles and a mostly mobile audience. The work: keep it responsive and stable while features, content and markets keep changing.

Context
NRGaming
Year
2023
My role
Lead delivery of the client application — architecture, performance and production stability
Integrations Platform Client Sports data Game providers Accounts & wallet Platform services backend · data HTTP · WebSocket Client application web · mobile-first Users, mostly on mobile continuous live updates · 900+ titles · peaks around major events
Simplified system view — for illustration

The product

PMBet is a leading online sports and casino product in Tanzania: live sports data, a catalogue of 900+ casino titles, and an audience that is predominantly mobile. It runs on the same multi-brand platform described in the Dashbet case study.

The problem

Live products don’t get quiet periods. Odds and match states change continuously, traffic rises around major events, and most users reach the product from phones rather than desktops. At the same time the product keeps changing — new features, new content, new markets. The challenge is to keep shipping without the product becoming slower or less stable.

What made it complex

  • Continuous real-time updates arriving over WebSockets, which have to reach the interface without overwhelming it.
  • A large catalogue — 900+ titles — that has to stay quick to browse on mid-range phones.
  • Several independent integrations — sports data, game providers, account and wallet services — each with its own behavior and failure modes.
  • Shared code. Work done for PMBet ships on a platform other brands depend on.

My responsibility

I lead delivery of the client application: its architecture, performance, maintainability and production stability. I work with product managers, designers, backend engineers, QA and DevOps to translate business requirements into changes that hold up in production.

Approach

  • Mobile-first as a constraint, not a layout. Performance and responsive design are planned for the devices and networks the audience actually uses, rather than adapted from desktop afterwards.
  • Real-time data as streams. Live updates arrive over WebSockets and are handled as RxJS streams within the application.
  • Features as platform capabilities. Where PMBet needs something new, it is built so the other brands on the platform can use it too.
  • Stability as an explicit responsibility. Changes go through CI/CD into a live product, so maintainability and production stability are treated as part of delivery, not as follow-up work.

Constraints and trade-offs

  • No maintenance windows. Changes land in a product that is in use around the clock.
  • Third-party behavior. Integrated services define part of the experience; the application has to degrade gracefully when they are slow or unavailable.
  • Shared platform. Brand-specific shortcuts are cheaper today and more expensive for every other brand tomorrow.

What changed

PMBet runs in production on the shared platform, serving live sports and a 900+ title casino to a mobile-first audience — with delivery continuing on the same codebase that the other brands use.

Technology

  • Angular
  • TypeScript
  • RxJS
  • WebSockets
  • CI/CD
PMBet — high-traffic, real-time consumer product
PMBet in production · pmbet.co.tz
Next case study