Absorbing tournament surges with 80% less admin work
A major esports organisation needed a fan engagement platform that holds up when six-figure crowds arrive at once. We built Pickem from scratch and moved the running of each tournament from people to the platform.
Every bigger tournament cost more to run
A major competitive esports organisation was expanding globally, and its tooling for tournament-time fan engagement could no longer take the load. During top-tier event windows, traffic spiked into six figures of concurrent users.
The cost side moved the wrong way too. Each event was more complex than the last, and the operational cost of running a tournament was growing faster than the audience.
The brief: a complete rebuild of the primary interactive hub for the client's largest global events, on an architecture that would not need re-architecting at the next traffic milestone.
Traffic arrived as a wall
Load did not ramp up gently. The platform had to expand almost instantly past 100,000 concurrent users and keep live leaderboards accurate while it did.
Operating costs outgrew the audience
More complex events meant more manual work every tournament weekend. The client wanted the platform to reduce that load instead of adding to it.
Accounts hold real value
Digital assets in this ecosystem are worth money, so account security was a primary design constraint. The authentication pipeline had to be custom-built for that threat model.
Four decisions that let the platform carry the load
Split fan traffic from admin tools
Fan engagement and administration have very different load profiles, security needs and release cadences. We ran them as separate services on AWS EKS, so a surge on the public side can never take down the tools staff use to run the event.
Compute the leaderboard before anyone asks
The leaderboard is what fans watch most and what breaks first under load. Rankings for over 100,000 participants are pre-calculated in PostgreSQL materialised views and refreshed in the background, so they stay live in the final seconds of a championship.
Let the platform run the tournament
A server-side timing engine locks prediction windows sixty seconds before each match and recalculates points the moment a result is verified. Work that used to fill tournament weekends became a configuration step before the event.
Show support exactly what the user sees
Support staff can enter a protected, view-only impersonation mode and see the platform as a specific user does. It paid back fastest on tournament days, when ticket volume rises with the crowd.
Weeks 1–4 · Discovery and architecture
Domain model, blueprint, decision records.
Weeks 5–12 · Build
Microservices core and responsive SPA from scratch.
Weeks 13–16 · Hardening
Load tests simulating 100K+ users, end-to-end QA.
Month 5 · Launch
Global deployment for a major tournament cycle.
After launch · Optimisation
Component reuse and behavioural analytics.
Built for the next tournament cycle, too
Pickem met or exceeded every strategic KPI set for the engagement, under live tournament conditions rather than in benchmarks. The project then moved into continuous optimisation, which MetaProject runs together with the client.
Current work targets 70% component reuse for future global event cycles and adds behavioural analytics to refine the engagement journey for the next generation of tournaments.
99.9%
uptime at the peaks of major tournaments
100K+
concurrent users supported
80%
less administrative labour
10+
languages via real-time localisation
99.9%
uptime during major tournament peaks
100K+
concurrent users through horizontal scaling
80%
reduction in administrative labour
< 100ms
global API latency, under 50ms at the edge
60%
faster support resolution
10+
languages supported
A from-scratch tournament engagement platform: decoupled fan and admin services, a leaderboard engine, a real-time WebSocket layer, an automated admin suite, tournament archiving and gamified user tiers.
Node.js + NestJS · Prisma · BullMQ · PostgreSQL · Redis · Centrifugo · Next.js + TypeScript · Tailwind CSS · MUI · AWS EKS · CloudFront · S3 · GitHub Actions · JMeter · Grafana
Questions about this project
How do you architect a platform to absorb six-figure traffic surges?
The combination that worked here is cloud-native microservices on AWS EKS with automated horizontal scaling, fronted by CloudFront for edge delivery. The architectural discipline matters more than any individual choice. Decoupling user-facing services from administrative ones means surge traffic on the public side can never destabilise the admin tools, and load on the leaderboard service can never affect authentication.
How do you build real-time leaderboards that stay correct under load?
For Pickem, the answer was PostgreSQL Materialised Views with a concurrent refresh strategy. Rankings are pre-calculated in the background, so retrieval is sub-millisecond regardless of how many data points are being written simultaneously. The right pattern depends on the workload, but materialisation engines win for read-heavy real-time ranking under almost any conditions.
How does automation actually reduce the cost of running global events?
By moving the orchestration of each tournament from people to the platform. Pickem's server-side timing engine locks interaction windows, verifies results, and triggers bulk recalculations automatically. The administrative work that used to fill tournament weekends is now a configuration step before the event. In this engagement, that came out to around an 80% reduction in administrative labour.
Why microservices rather than a well-structured monolith for a platform like this?
For most products, we'd push back on automatic microservices adoption, because most teams end up with a distributed monolith and worse operability. For Pickem, the case was clear: user-facing engagement and administrative management have radically different load profiles, security requirements, and deployment cadences. Decoupling them was an architectural property the platform genuinely needed, not a default.
Can you share more about the client?
The client name is withheld under NDA. Pickem is the publicly visible product name and the work itself can be discussed at the level you see on this page. For more detail, including reference conversations, get in touch and we can walk you through what's possible.
See more cases
Does your platform have to survive its own success?
Tell us what you are building. We will come back with an honest view of how we would approach it.