Platform

How the whole thing is put together.

Four portals, one event log, twenty-one services and a sport plugin boundary that means adding cricket does not touch the code that scores a basketball quarter.

Applications

Four portals

Public platform

Discovery, live scores, match centre, teams, athletes, rankings, news and media. Mobile-first and crawlable.

HomeSportsLiveTournamentsMatch centreTeamsAthletesRankingsNewsSearch

Open

Organizer portal

The SaaS surface: create competitions, register teams, schedule fixtures, assign officials and sell sponsorship.

DashboardWizardFixturesRegistrationsOfficialsSponsorsAnalyticsSettings

Open

Scorer console

A purpose-built scoring terminal. Offline-capable, keyboard-driven, auditable, deliberately plain.

AssignmentsMatch lobbyLive scoringEvent historySync statusSubmit

Open

Admin control

Tenants, verification, sport configuration, API quotas, payments, audit log and service health.

OrganizationsUsers and rolesSportsAPI tenantsPaymentsAudit logHealth

Open

The core

Everything hangs off one event log

A scorer taps a button. That produces one immutable event. Every other part of the system is a consumer of that event, which is why the box score, the standings, the ranking, the sponsor impression count and the fan's phone can never disagree with each other.

01 Scorer

taps +3

02 Scoring service

validates against the ruleset, assigns sequence

03 Event broker

fans out to every consumer

04 Consumers

live UI, statistics, notifications, analytics, API

05 Fan

sees 78 in under a second

The event envelope

Every scoring event carries the same eight fields, whatever the sport. This is what makes replay, correction, audit and idempotency possible at all (§52).

{
  event_id        // idempotency key
  match_id
  sequence_number // monotonic, per match
  timestamp       // device clock, ISO 8601
  actor_id        // who recorded it
  event_type
  payload         // sport-specific
  version
}

The ten rules that shape everything

The scoring engine stays up even if every other service is down.
Historical scoring events are never modified.
Scoring uses event sourcing, so state is derived not stored.
Every scoring event is attributable and auditable.
Realtime delivery is separate from page rendering.
Sport rules are configuration, never hard-coded.
The platform is API-first; the website is a client.
The platform is multi-tenant from the first table.
Public pages are server-rendered and crawlable.
Every major module scales independently.

Architecture

Twenty-one services

Split on failure domains, not on org chart. Scoring is isolated so a slow search index or a misbehaving notification queue can never take a live match down.

API gateway

Routing, auth, rate limits

Identity

User

Profiles and role assignment

Organization

Tenants and membership

Tournament

Competitions and stages

Competition

Formats and standings

Match

Lifecycle and state machine

Scoring

Event ingest, the critical path

Statistics

Derived per-sport metrics

Athlete

Profiles and career records

Team

Rosters and eligibility

Venue

Courts, rings and availability

Notification

Push, email, SMS, WhatsApp

Media

Photos, video, transformations

Content

News and CMS

Ranking

Configurable rating formulas

Payment

Gateways, invoices, refunds

Sponsorship

Inventory and delivery

Analytics

Aggregation and reporting

Search

Indexing and typo tolerance

Developer

Keys, quotas, usage

Multi-tenant from the start

Platform, then organizations, then tournaments, matches, teams and athletes. Tenancy is enforced in the database, the API, storage and analytics, not just in the UI.

Row-level isolationTenant-scoped keysPer-tenant storage prefixesSegregated analytics

Security posture

RBAC across 13 rolesEncryption in transitEncrypted PII at restArgon2id hashingToken rotationRate limitingAudit loggingCSRF and XSS defencesParameterised queriesSecure headersInput validationService-level checks

Built to leave one country

No assumption of a single timezone, currency, language or governing body. Locale, currency and date formatting are per-tenant, and the copy layer is translation-ready.

EnglishHindiSpanishFrenchArabic (RTL)Timezone-awareMulti-currency

Reference stack

Layer	Choice	Why
Frontend	Next.js, React, TypeScript	SSR and static generation for SEO
Styling	Tailwind plus a design system	One token set across four portals
Backend	Node.js, TypeScript, NestJS	Clear service boundaries, OpenAPI
Database	PostgreSQL	Constraints and transactions where it matters
Cache	Redis	Live match state and pub/sub
Broker	Kafka or NATS	Ordered, replayable event streams
Search	OpenSearch	Typo tolerance and relevance tuning
Storage	S3-compatible object storage	Media, documents and exports
Deploy	Docker, Kubernetes at scale	Cloud-neutral across AWS, Azure, GCP

Delivery phases

Phase 1Foundation

Auth, users, organizations, RBAC, sports, teams, athletes, venues
Phase 2Tournament management

Creation, formats, registration, fixtures, officials
Phase 3Live scoring

Three scoring engines, scorer portal, realtime, match centre
Phase 4Public platform

Home, tournament, team, athlete, results, standings, statistics
Phase 5API platform

REST, WebSocket, webhooks, keys, developer portal, widgets
Phase 6Media and money

News, photos, video, sponsors, ads, payments, subscriptions
Phase 7Advanced

Offline scoring, analytics, white-label, PWA, rankings, more sports

About this build

What is real here, and what is not

Honesty beats a convincing mock. This build is the public platform and the product story, with a genuinely working scoring core.

Actually working

The three sport rulesets, the event-sourced scoring engine, append-only corrections, the offline queue, the live match simulation, discovery filters, tabs and follow state.

Described, not implemented

Authentication, payments, the real WebSocket transport, storage, search, notifications and the twenty-one services. Buttons that would need those say so when you press them.