365 Scores

The challenge

moblers tackled several major challenges in building a fast, scalable, and globally adaptive sports app:

Real-time data delivery: Handling thousands of simultaneous live updates across sports and time zones.

User preference engine: Flexible personalization based on teams, players, and sports types.

Notification infrastructure: Instant, reliable alerts to millions of users without delay.

The solution

moblers engineered a responsive mobile platform that delivers live sports data at scale, with an intuitive user experience and high reliability.

Live score tracking: Real-time updates for matches in football, basketball, tennis, and more.

Custom notifications: Alerts only for the teams and sports the user cares about.

Curated content: Personalized news, highlights, and match recaps.

Multi-sport coverage: From local leagues to international tournaments — all in one app.

Evidence boundary

The public project record confirms: a mobile sports platform with live match tracking, a user preference engine, notification infrastructure designed for millions of users, curated content, multi-sport coverage, a 5-month delivery, and full client ownership of source and artifacts. A moblers blog post also publishes that the 365 Scores real-time soccer scores app had more than 100 million installs at the time of that article (source).

The following are not publicly disclosed and are not inferred here: primary backend language/framework, mobile client framework (native iOS/Android, Flutter, React Native, or other), real-time transport, databases and cache, message broker, cloud/CDN, analytics/monitoring/push vendors, sports-data provider names, admin/CMS ownership, CI/CD and SRE scope, maintenance SLA, client testimonial wording, and numeric production KPIs other than the published 5-month timeline, “millions of users,” and the blog’s 100-million-install figure.

Architecture diagrams and pipeline descriptions below are a representative live-sports delivery pattern that matches the published product boundary. They are not the confidential 365Scores production graph.

Scope and deliverables

Verified as delivered by moblers

• User-facing 365Scores mobile app capabilities: live score display, match tracking, team/league/sport selection, and curated content.
• Real-time score delivery and notification behavior for match updates, goals, red cards, and other key events.
• User preference / personalization features so users receive tailored alerts, news, and summaries.
• 5-month engagement to complete the published product.

Not published as yes/no deliverables

• Which client binaries were in scope (iOS, Android, web) and whether they were native or cross-platform: not publicly disclosed.
• Backend/APIs and admin/operations/CMS dashboard: not publicly disclosed.
• Named third-party sports-data, analytics, ads, identity, or payment integrations: not publicly disclosed.
• Automated tests, load tests, UAT artifacts, CI/CD, infrastructure-as-code, and monitoring runbooks: not publicly disclosed.
• Hosting, ongoing SRE/operations, handover documentation, and maintenance SLA (duration and terms): not publicly disclosed.
• Client testimonial or quote: none published on the project page.

Technical architecture and integrations

Sports data sources (licensed feeds / APIs — providers not public)
        │  ingest (webhook, stream, or poll — not public)
        ▼
┌──────────────── ingestion & normalization ────────────────┐
│ Validate, dedupe, map events (goal, card, state change)   │
└──────────────────────────┬────────────────────────────────┘
                           │ message/stream backbone (not public)
                           ▼
┌──────────── processing & personalization ─────────────────┐
│ Match state store  │  preference index  │  content filter │
└─────────┬──────────────────────┬──────────────────────────┘
          │ live API / subscribe │ fan-out to push pipeline
          ▼                      ▼
   Mobile clients          Notification workers
   (live scores,           (segment → batch → provider)
    recaps, news)                 │
                                  ▼
                     Push / in-app alerts to users

Data sources and ingestion. The product integrates live sports data. Provider names, feed formats, and whether ingestion used webhooks, streaming, or polling are not public.

Real-time pipeline. Published requirements are concurrent live updates across sports and time zones. A representative design normalizes events, publishes them on a durable stream or queue, and fans them out to API subscribers and the notification path. The actual broker (Kafka, Redis Streams, or other) is not disclosed.

API layer and mobile clients. Clients display live scores and subscribe to match updates. Public/internal API shapes, SDKs, and transport (WebSockets, HTTP/2 SSE, MQTT, or vendor SDK) are not public.

Notification flow. A representative path is: match event → preference match → enqueue → batch/rate-limit → push provider → retry on failure. The production trigger, queue, provider (FCM, APNs, gateway, or custom), and retry policy are not public.

Caching, CDN, and edge. Global low-latency delivery is a published goal. Cache keys, CDN, and failover topology are not public.

Monitoring and failover. Observability and resilience controls used in production are not public. A release-grade system in this class typically tracks ingest lag, event-to-push latency, delivery errors, and client crash-free sessions — without claiming those tools were used here.

Technology stack and platform specifics

Verified stack boundary: mobile sports application; real-time sports data delivery; push/notification infrastructure for large concurrent audiences; preference engine for teams, players, and sports.

Concrete products are not listed on the public project page:

• Mobile frameworks and languages (Swift, Kotlin, Flutter, React Native, or other): not publicly disclosed.
• Backend language and framework (Node/Express, Java/Spring, .NET, or other): not publicly disclosed.
• Real-time transport and streaming (WebSockets, SSE, MQTT, Firebase Realtime, custom sockets): not publicly disclosed.
• Primary database, cache, and time-series store (PostgreSQL, Redis, Cassandra, or other): not publicly disclosed.
• Message broker (Kafka, RabbitMQ, Redis Streams, or other): not publicly disclosed.
• Push services (FCM, APNs, OneSignal, Firebase, in-house): not publicly disclosed.
• Hosting, CDN, and runtime (AWS/GCP/Azure, CloudFront/Cloudflare, Kubernetes, serverless, VMs): not publicly disclosed.
• Analytics, A/B testing, and error tracking: not publicly disclosed.
• Sports-data providers and whether feeds were licensed or self-hosted: not publicly disclosed.
• DevOps/CI/CD and monitoring tools: not publicly disclosed.

Do not treat a representative pattern as a product name. A numeric or named stack table can be published when 365Scores approves the list and a one-line reason for each choice.

How personalization and notification delivery operate at scale

Verified behavior: users select teams, leagues, players, and sports; alerts and curated content are filtered to those preferences; notifications cover match progress, goals, red cards, and other key events; the infrastructure was engineered for millions of users.

Representative operating model (not a production claim):

1. Preference storage. Store durable preferences in an indexed store and keep a hot subset in cache so send-time segmentation is a lookup, not a full scan. The actual engine type (rule-based, ML, or hybrid) is not publicly disclosed.
2. Send-time segmentation. On each normalized event, resolve who should be notified (followers of the match, team, player, or league) and drop users who muted that event type.
3. Notification pipeline. Segment → enqueue → batch → route to the push provider → apply rate limits and backoff. Provider names and sharding/worker topology are not publicly disclosed.
4. Monitoring and retries. Track delivery rate, latency, and errors; retry transient provider failures; dead-letter poison messages. Production metrics and SLAs are not publicly disclosed.

On low-signal devices or poor networks, keep the live score path independent from push so the in-app board can continue if a notification is delayed.

Results and measurable outcomes

Confirmed timeline: completed in 5 months.

Published scale language: engineered for instant, reliable alerts to millions of users, with multi-sport live coverage from local leagues to international tournaments. A moblers article published more than 100 million installs for the 365 Scores real-time soccer scores app (blog source). Install-count measurement date, store, and methodology beyond that caption are not restated on the project page.

Requested production KPIs that are not publicly disclosed (no measurement period or methodology is public unless noted):

• Monthly active users (MAU): not publicly disclosed.
• Peak concurrent users or connections during major events: not publicly disclosed.
• Notifications throughput at peak (per second or minute): not publicly disclosed.
• Average end-to-end notification latency (event → device) and delivery success rate / SLA: not publicly disclosed.
• Crash-free rate or other stability metrics: not publicly disclosed.
• Core-service uptime / 99.x% availability during tournaments: not publicly disclosed.
• Before/after API latency, error-rate, or other performance deltas: not publicly disclosed.
• Average vs peak notifications per hour: not publicly disclosed.

Conservative rounded metrics can be added when 365Scores approves the figure, cohort, and measurement window (for example first 30 days after launch or a named season).

Architecture caveats

• The diagrams use generic component names. They are not the 365Scores production topology.
• “Millions of users” and the blog’s 100-million-install caption are the published scale statements; they are not MAU, DAU, or peak-concurrency figures.
• Sports-data licensing, push-provider contracts, and store policy sit with the client and vendors; they are not listed here.
• No unnamed framework, cloud product, or SLA in this guide should be attributed to 365Scores without written approval.