An online gaming platform on AWS, architected and built end to end.

The challenge

When we started, the platform was one monolith on self-managed servers on the operator's own premises, with one database underneath every feature. Deploys and scaling were manual and nothing was defined as code.

The product was growing fast, every feature moved real money, and traffic arrived in sharp peaks. The monolith could not scale the parts under load independently, and every release risked the whole platform.

The constraints

• Real money: every balance change must be traceable, and a payout must never go out by mistake.
• Many external integrations, each with its own failure modes.
• Real-time features and sharp traffic peaks.
• A public target for bots and floods.
• A small team that needed to release safely every day.

Decisions & tradeoffs

Event-driven services. We split the monolith along domain boundaries. Services that answer users scale on CPU and requests; work that can wait goes onto queues and is processed by workers that KEDA scales from zero with the queue depth. Events leave each service through a transactional outbox, so nothing is lost and nothing is processed twice.

Money safety by design. Every movement of money is a posting in a double-entry ledger, every money API is idempotent, and automatic payouts run through a chain of deterministic checks that fails closed: anything unexpected goes to a person. An AI reviewer can advise, but never move money.

Secure by design. Edge protection with a WAF, rate limits and bot rules; workloads only in private subnets; engineers through SSO, Zero Trust and VPN; organization-wide CloudTrail, GuardDuty and Security Hub; signed and scanned images; secrets in AWS Secrets Manager with rotation and one least-privilege role per service.

Cost-optimized by design. Workers scale to zero, Karpenter right-sizes and consolidates nodes, stateless work runs on Spot and Graviton, Savings Plans cover the steady baseline, read replicas take read traffic, and bots are stopped at the edge instead of being paid for.

The implementation

Migration. We moved the platform from its on-premises servers to Amazon EKS and its data to Amazon Aurora, switching production over in a planned window.

Accounts and infrastructure as code. Terragrunt defines an AWS Organization with separate management, development and production accounts, each production network spread across three Availability Zones. Services get their cloud resources and permissions from their own deployment definitions.

Delivery. Every change goes from Git through CI, tests and image scanning to a registry. Kargo promotes it from development to production by committing to the GitOps repository, and Argo CD applies it to each cluster.

Observability and AI operations. Monitoring runs centrally in the management account: metrics, logs and traces from every account, with alerts routed to the team that owns them. AI agents run beside it to triage alerts and summarize incidents, and they can investigate but never change production.

Outcomes

The operator moved from one on-premises monolith to a platform where each part scales on its own, idle work costs nothing, every release is an auditable promotion, and money can never move by mistake. The platform has absorbed flood attacks without taking players offline.

Handover & ongoing ownership

Runbooks, alert routing and every piece of infrastructure and configuration live in the operator's own repositories.