Pickem

Q: 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.

Q: 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.

Q: 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.

Q: Why microservices rather than a well-structured monolith for a platform like this?

For most products, we'd push back on automatic microservices adoption — 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.

Q: 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.

Powering peak tournament engagement with a cloud-native platform built to absorb traffic surges, not fold under them.

Europe

99.99%

Peak uptime during major tournament cycles

100K+

Concurrent users supported through automated horizontal scaling

80%

Reduction in administrative labour

< 100ms

Global API latency

Client name withheld under NDA. Pickem is the publicly visible product name; metrics verified through joint post-launch review.

Tablet screen showing a Budapest Major 2025 gaming event page with a person spray painting a wall and game prediction options.

Website interface for Budapest Major 2025 with a character painting a match bracket on a wall and a yellow button labeled Predict Now.

#Esports

#High-Concurrency

#Cloud-Native

#Microservices

#Real-Time

#AWS

#Kubernetes

Summary

A major competitive esports organisation reached a point in its global expansion where the existing tooling for tournament-time fan engagement could no longer absorb the load. Traffic during top-tier event windows spiked into six figures of concurrent users, and the operational cost of running each tournament was growing faster than the audience. We built Pickem — a tournament prediction and engagement platform — from scratch as a cloud-native microservices system. The result is a platform that turns traffic surges into engagement rather than incidents, and an operating model that reclaimed roughly four-fifths of the administrative load.

Request

The brief was a complete rebuild, not an iteration. The client needed a new tournament engagement platform — the primary interactive hub for its largest global events — that could deliver three things simultaneously:

A highly scalable infrastructure that wouldn't need re-architecting at the next traffic milestone

A professional administrative suite for managing real-time tournament logic without manual choreography

A low-latency user experience that worked equally well in Europe, North America, and Asia

The platform also had to evolve alongside a rapidly changing competitive gaming market — meaning the architecture itself had to be easy to extend, not just operate.

Challenge

Four pressures shaped the engineering approach.

Surge scaling.

The platform had to absorb traffic spikes well past 100,000 concurrent users without performance degradation. Steady-state autoscaling isn't enough when the load curve is more "wall" than "ramp" — the system had to handle near-instantaneous expansion.

Operational margin.

As global events grew more complex, the cost of running each one was rising. The client wanted the engineering of the platform itself to reduce administrative load, not just enable more of it.

Account integrity.

Digital assets in the ecosystem carry real value, which makes account security a primary design constraint rather than a checkbox. The authentication pipeline had to be custom-built to handle the threat model.

Real-time data freshness.

Live leaderboards and community feeds across millions of interactions needed a materialisation strategy that stayed accurate under heavy load — not just fast under light load.

Feature scope

Decoupled microservices architecture

User-facing operations and administrative management completely separated for fault isolation

High-velocity materialisation engine

Pre-computed ranking and leaderboard data, refreshed continuously, retrievable in sub-millisecond windows

Real-time WebSocket layer

Push-based communication for live feeds and community updates

Bespoke admin suite

Automated tournament lifecycle management and result dissemination

Gamified progression system

Dynamic user tiers and automated social-sharing for organic engagement

Tech stack

Backend:

Node.js, NestJS, Prisma ORM, BullMQ (task queuing), PostgreSQL, Redis (caching), Centrifugo (real-time backend-frontend communication)

Frontend:

Next.js, TypeScript, Tailwind CSS 4.0, Material-UI (MUI)

DevOps:

AWS EKS (Kubernetes), Amazon CloudFront (global CDN), S3, GitHub Actions for CI/CD

QA:

Manual QA on isolated staging and production smokes, JMeter for stress and load testing, Postman and Swagger for API contract tests, Grafana for logs and monitoring

Key Features

Real-time leaderboard materialisation

The leaderboard is the part of the system fans see most, and the part that breaks first under load. The platform uses PostgreSQL Materialised Views to pre-calculate rankings for over 100,000 participants, with dynamic calculation-rule editing for tournament-specific scoring. Views refresh concurrently through automated background tasks, which gives the platform sub-millisecond data retrieval and keeps the leaderboard accurate and live — including during the final seconds of a championship, when both load and stakes peak.

Gaming leaderboard interface on tablet displaying top three players with crowns and a ranking list of nicknames and points.

View-only admin impersonation

A practical operational feature, not a flashy one — and one that paid back faster than expected. Support staff can enter a View-Only Impersonation Mode through a protected endpoint, seeing the platform exactly as a specific user does. This let the support team resolve inquiries roughly 60% faster, which mattered most on tournament days when ticket volume otherwise spiked alongside concurrent users.

Automated tournament lifecycle

The platform's core operational logic is governed by a precise server-side timing engine that removes the need for manual intervention. Interaction slots lock exactly sixty seconds before events begin. Bulk point recalculations trigger the moment a result is verified, instantly updating user rankings and medals globally. The administrative team no longer choreographs the tournament — the platform does.

Laptop screen showing a 3D prediction map with labeled stages, including locked Stage 1, Stage 2, Play-off Stage, and unlocked Stage 3, MVP, Frequent Skin, and Best Map points connected by a bridge over water.

Tournament archiving with read-only access

Completed tournaments are archived with their full user data and statuses preserved. Users keep access to their achievements from past events. Administrators can continue editing tournament content (for example, retrospective adjustments or content corrections) without disturbing the archived state.

Timeline

Weeks 1–4

Strategic discovery and architecture

Domain-driven design modelling, architectural blueprinting, decision records for every consequential trade-off.

Weeks 5–12

Build

From-scratch development of the microservices core and responsive SPA.

Weeks 13–16

Hardening

Intensive load testing (simulating 100K+ concurrent users) and end-to-end QA.

Month 5

Launch

Global deployment for a major tournament cycle.

Results

Summary

Across every strategic KPI the engagement set, the platform met or exceeded the target — and it did so under live tournament conditions, not in benchmark tests.

Results in Numbers

99.99%

uptime maintained during the most intensive peaks of major tournament cycles

< 50ms

edge response time and < 100ms global API latency via optimised edge delivery for international audiences

100,000+

concurrent users supported seamlessly through automated horizontal scaling

80%

reduction in administrative labour via the transition to automated tournament lifecycle management

10+

languages supported through a real-time localisation workflow

Next steps

The project has moved into a continuous optimisation phase. This includes a 70% component reuse strategy for future global event cycles, and the integration of behavioural analytics to refine the engagement journey for the next generation of tournaments.

F. A. Q.

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 — 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

Product Company Capability Expansion

Doubling the feature delivery capacity of a B2B SaaS engineering team without doubling headcount.

#SaaS

#B2B

#Microservices

#Platform Engineering

#CoE

#Cloud-Native

#AWS

#Kubernetes

#Knowledge Transfer

Skin.Club CS2 skins guide webpage displaying various weapon skins and knife designs including Doppler, Ultraviolet, Marble Fade, Freehand, and Damascus Steel.

This is some text inside of a div block.

Healthcare Compliance Platform

Re-architecting a clinical SaaS for HIPAA and GDPR compliance while expanding product capabilities.

#HealthTech

#Compliance

#HIPAA

#Kubernetes

#GDPR

#Cloud-Native

#Microservices

#AWS

#PostgreSQL

DevSecOps

This is some text inside of a div block.

Pickem

Powering peak tournament engagement with a cloud-native platform built to absorb traffic surges, not fold under them.

#Esports

#High-concurrency

#Cloud-Native

#Microservices

#Real-Time

#AWS

#Kubernetes

This is some text inside of a div block.

Building a platform that has to survive its own success?

If you're architecting a system where traffic surges aren't an edge case but a regular event — esports, ticketing, drops, live events — the engineering discipline is specific and the patterns are well-understood. That's where we start.

Start a Capability Blueprint Workshop