E-commerce2026· GamesTheShop — India

GamesTheShop

A custom commerce platform for India's largest gaming retailer

A replatform off a legacy monolith onto Node/Express and Django microservices on ECS Fargate, sized for launch-day concurrency and digital key fulfilment.

Headline outcome

48,000 concurrent users · 1.1s load time · 34% conversion lift

Flat white carton packaging laid out on a pale surface — Illustrative photography. No imagery on this site is from a client environment.

Next.jsDjango / DRFNode / ExpressECS FargatePostgreSQL 16OpenSearchAWS CDK

Overview

GamesTheShop sells games, consoles, collectibles and digital keys across India. The store it replaced was a legacy ASP.NET Web Forms monolith: server-rendered pages, no test suite, scheduled jobs triggered by hitting a page, and a single deployable that could only be scaled by making the server bigger. The brief was a platform the retailer owns outright, running in their own AWS account, that holds up on the hours that matter.

Challenge

A game launch is the worst hour of the year and the most visible one. The storefront had to take launch-day concurrency on the read path while the write model stayed consistent — pre-orders across platforms, physical stock and one-time digital keys, where releasing the same key twice is not a glitch but a loss.

Solution

Two services with one owner each: a Node/Express storefront API for search, cart, checkout and live updates, and a Django back-office API that owns the write model and the source of truth. Next.js applications for the storefront and the admin dashboard behind CloudFront and an ALB with WAF, on an ECS Fargate cluster in ap-south-1. Multi-AZ RDS Postgres 16, Redis for the queue and the cart, OpenSearch for product search, S3 for media and invoices. Celery and BullMQ workers carry email, labels, indexing and the payment path; the payment callback is verified against its signature before an order is allowed to progress. The whole runtime is defined in AWS CDK, so it can be rebuilt from the definition.

Outcome

48,000 concurrent users on launch day at a 1.1-second page load, a 34% conversion lift, and no downtime on a launch. The client owns the source, the schema and the infrastructure definitions.

Measured

48,000

concurrent users on launch day

1.1 s

page load

34%

conversion lift

Fargate tasks in production

The constraint that shaped it

A release date is not negotiable. A major title goes on sale at an announced hour and the traffic arrives whether the platform is ready or not, so capacity had to exist before there was any load to measure it against. That forced the separation: read paths away from the write model, search on its own cluster, cart in its own Redis, and money gated behind a verified callback. 48,000 concurrent users at a 1.1-second page load.

How it was built

One write model, one owner

Two APIs share the estate and neither is the other’s copy. The Node/Express storefront API carries search, cart, checkout and live updates — the paths that take launch-day concurrency. The Django back-office API owns catalogue, orders and fulfilment, and owns the write model, so a staff action and a customer order resolve against the same Postgres 16 source of truth. Cart state and the job queue sit in separate Redis instances, so a busy checkout cannot starve a worker. Search runs on its own OpenSearch cluster, where a heavy query costs latency rather than stock accuracy.

The money path is a boundary, not a step

An order does not progress until the payment callback has been verified against its signature. That check is the boundary: before it, an order is an intent; after it, fulfilment is allowed to begin. Nothing downstream — courier label, confirmation email, search index update — is triggered from inside the checkout request, so a slow integration delays a notification instead of a purchase. A dedicated payment worker on BullMQ carries the follow-on work, with Celery Worker and Celery Beat taking email, labels, indexing and scheduled jobs.

What the store team actually sees

Staff do not administer AWS; they work a dashboard. The admin application is its own Next.js SPA behind the same front door as the storefront, reached by path-based routing through the load balancer and firewall, so a price change or a fulfilment action is an ordinary screen and not a console. Shopper identity runs through Google sign-in. Login codes and order updates go out over SMS and WhatsApp, and transactional mail through SES — the channels an Indian buyer already reads, wired as first-class paths rather than afterthoughts.

Change is a reviewed code change

The runtime is defined in AWS CDK and pinned to ap-south-1, so the cluster, the routing rules, the firewall and the data plane can be rebuilt from the definition rather than reconstructed from memory. Availability is set at that same layer: Multi-AZ Postgres, a two-node search cluster, a NAT gateway per availability zone. The architecture was walked band by band against the running production estate and verified on 3 July 2026. We own the architecture and run the infrastructure under an SLA engagement.

Stack, by concern

Edge & front end

Next.js SPA — storefrontNext.js SPA — adminAWS AmplifyCloudFront + OACALB + WAF

Services & runtime

Node / Express storefront APIDjango / Python back-office APICelery Worker + BeatBullMQ payment workerECS FargateAWS CDK

Data plane

RDS Postgres 16Redis — brokerRedis — cartOpenSearch 2.13Amazon S3

Integrations

PaytmBlueDartVaultNEpayGoogle Sign-inAWS SESInteraktKaleyra

More work

EMSPL Fleet Intelligence

AI Fleet Management for 2,400 Vehicles

Neurobloom AI

AI-Powered D2C Wellness Commerce

All case studies Start a project