Case study · Product Lead · Backend Architecture
Rebuilding CricTracker
without losing a click.
I moved a high-traffic cricket news platform from a legacy WordPress setup to Node.js, Next.js and GraphQL, and kept its SEO, performance and revenue intact through the switch.
01 Business context
High traffic,
no room to break.
CricTracker is a leading cricket news and fantasy platform with tens of millions of monthly users, and most of that traffic comes from organic search. Any drop in SEO would have meant an immediate loss of revenue, so moving fast and breaking things was off the table.
The WordPress monolith, meanwhile, was hitting its scaling limits and getting harder to change with every release.
02 What I built
A modern stack,
end to end.
Federated GraphQL backend
A Node.js (Express/Apollo) GraphQL layer over MongoDB, PostgreSQL and Redis. Features were split into microservices (content, users, matches, stats, search) and composed into a single graph with Apollo Federation.
Next.js frontend
The site moved to Next.js with SSR and ISR, built-in image optimization and aggressive edge caching through CloudFront and Cloudflare.
Real-time layer
Live scores, fantasy leaderboards and notifications pushed over Socket.io, with fan-out through Redis pub/sub to absorb traffic spikes during big matches.
03 Key challenges
Hard problems,
solved in order.
01SEO-safe migration
Organic search drove the business, so URL structures, meta tags, canonical tags and schema markup had to survive while everything underneath changed.
I built a compatibility layer that mapped legacy WordPress slugs and routes to the new Next.js pages, added 301 redirects where paths had to change, and verified crawlability and Core Web Vitals. We mirrored the old sitemap and shifted traffic gradually through load balancer rules, watching for SEO regressions at each step.
02Data migration & consistency
WordPress content lived in MySQL, with much of its structure defined by plugins.
I designed ETL jobs that normalized historical articles, categories, tags and user-generated content into MongoDB and PostgreSQL. Both stacks ran on dual-write for a period, and we validated data consistency and performance with synthetic and real traffic before cutting over.
03Performance at scale
The platform served 10M+ requests a day, with p99 targets under 50ms for key APIs.
MongoDB sharding and Redis caching carried most of the load. I tuned hot queries with the right indexes and aggregation pipelines (some went from ~500ms to under 50ms), batched GraphQL resolvers to remove N+1 queries, and put heavy read paths behind the CDN.
04Cost optimization
Alongside the migration I led an AWS cost review that brought annual spend down from roughly ₹3L to ₹1L.
That meant right-sizing EC2, replacing always-on large instances with auto-scaling groups, moving more reads to CDN and Redis, removing idle resources, and revisiting RDS and ElastiCache instance classes. We also merged a few microservices where the split cost more in infrastructure and operations than it returned in flexibility.
04 Why it mattered
Business impact,
owned end to end.
For the business, the result was a modern, scalable architecture with real-time features and a much smaller AWS bill, shipped without giving up SEO or uptime.
For me as an engineer, the project touched nearly every layer: data modeling and migration, distributed systems, GraphQL federation, Next.js SSR/ISR, real-time WebSockets, observability and cost optimization at scale. I was responsible for both the technical complexity and the business outcome.