Engineering a real-time betting platform for performance, resilience, and growth

• Unpredictable spikes during sports events led to latency above acceptable thresholds (P99 > 2s), compromising core user workflows.
• Backend throughput plateaued at ~140 RPS, blocking user scale and stressing transactional endpoints.
• Database-level deadlocks triggered cascading service outages due to unbounded query payloads.

• Python-based independent streaming processes created memory bloat, CPU exhaustion, and deployment friction.
• Markets often failed to update in time, especially when supporting 20K+ market live feeds.

• Service-wide outages were triggered by silent proxy bypass, logging overloads, and lack of monitoring guardrails.
• Operational runbooks and observability pipelines were insufficient for root-cause analysis.

• Dashboard APIs triggered recursive joins across user hierarchies, causing long query times and data inconsistencies.
• Real-time visibility into betting PnL was inconsistent and unstable.

• Feature delivery was unpredictable post-MVP due to siloed responsibilities and backend/frontend misalignment.
• Rework and missed expectations increased due to late integration and fragmented QA cycles.

• The platform's first-touch user flow suffered from large bundle sizes, long FCP/LCP, and blocking tasks.
• Lighthouse scores dropped below 70, impacting SEO and user retention.

• Built a fully containerized platform on Kubernetes with namespaced isolation, pod-level scaling, and GitOps workflows via ArgoCD and Helm.
• Rewrote Python services in Go, cutting CPU usage from 6-8 cores to under 1 core and memory from 16 GB to under 500 MB per pod.
• Added Redis ElastiCache, PostgreSQL with failover, and Kafka with persistent topics for real-time message streams.
• Enhanced autoscaling logic via Karpenter and PerfectScale; enabled observability using OpenTelemetry.

• Replaced fragmented Python processes with a unified Go service using goroutines and persistent WebSocket connections.
• Reduced memory usage from 6 GB to 150 MB and CPU from 2.5 cores to 0.1 core.
• Added configurable goroutine pools, message queue backpressure controls, and fault isolation mechanisms.
• Introduced streaming observability with Prometheus, Loki, and custom Grafana dashboards.

• Applied query payload governance, setting upper bounds on joins, subqueries, and sort parameters.
• Added retry-safe transactional workflows and async processors for slow writes.
• Designed incident recovery playbooks with pinned session flushing, log pruning, and failover management.

• Transitioned to an AWS Control Tower model, segmenting dev, staging, and production environments.
• Integrated Google Workspace with AWS SSO to manage role-based access across developer, product, and quality teams.
• Applied SCPs, CloudTrail, and VPC Flow Logs to enforce security compliance.
• Set up Tailscale VPN routing and API firewalling for restricted services.

• Formed stable team pods around modular components like user management, configuration, and payouts.
• Shifted to API-first design: frontend and QA teams worked with mocked contracts before backend merges.
• Eliminated partial testing: a component entered QA only when fully integrated.
• Each sprint included demo-ready components with working frontend-backend logic.

• Built load-testing pipelines using k6 to simulate more than 2,000 concurrent bettors across a large set of market types.
• Detected bottlenecks in transactional APIs with 19s response times; reduced to under 250ms via query profiling and caching.
• Instrumented latency and error budgets across critical endpoints using P95/P99 metrics and OpenTelemetry.
• Enabled real-time autoscaling tied to event rate and request patterns.

• Replaced synchronous, recursive dashboard queries with an event-driven architecture using Kafka and Go.
• Implemented durable, Redis-backed event processing with pre-aggregation on key actions (bets placed, odds updated, user hierarchy changes) using hierarchical sync queues and DLQ processors.
• Dashboard load times dropped from 6-8s to sub-1s, even under high traffic.

• Lighthouse scores increased to 99, FCP dropped from 14.5s to 4.97s, and long tasks were eliminated.
• Refactored UI structure for accessibility, speed, and better LCP distribution.

Axelerant introduced structured performance profiling, rewrote core backend services in Go, and optimized database access with targeted indexing and payload decoupling. Backend throughput scaled from 140 RPS to 560+ RPS, validated under live load simulations. Key transactional endpoints (market transactions, odds fetch) were reduced from 2.3s P99 latency to under 250ms. Multiple layers of latency mitigation were applied, including caching of hierarchical lookups and compression of API payloads.

The streaming system was completely rebuilt in Go with a single persistent WebSocket connection and goroutine-based handlers for each market stream. Memory dropped from 6 GB to 150 MB, and CPU usage from 2.5 cores to 0.1 core per pod. The platform now supports 20,000+ concurrent live markets with no dropped connections or missed updates, even under active load. Built-in metrics expose internal state (queue lag, message time skew) for proactive recovery.

The platform's infrastructure was migrated into a multi-account, highly governed AWS setup. Development, production, logging, and shared services were fully isolated. Centralized logging, role-based access, and policy guardrails reduced surface area and improved operational clarity. Account-specific billing and tagging improved cost attribution per environment and per service. Guardrails like AWS Config and CloudTrail were activated organization-wide for compliance enforcement.

The legacy synchronous aggregation architecture was replaced with a Kafka-based event pipeline. Users, bonuses, and referral earnings are now pre-aggregated in real time and stored in durable Redis snapshots. Dashboard queries became lightweight reads instead of heavy nested joins. A live hierarchy sync mechanism was built to automatically propagate structural changes (user level changes, new agents). Admin dashboards now load in under a second, even with over 250 concurrent agents and thousands of downstream users querying simultaneously.