Global Fan.

The challenge

Clubs managed members, dues and tickets with spreadsheets, disconnected systems and manual checks at the gate. That meant scalping, identity fraud, long queues and little insight into their own fans.

The technical problem is extreme by nature: traffic is almost flat during the week and multiplies within minutes when sales open for a big match or when thousands of fans reach the stadium at once. Every ticket must be sold exactly once and every entry must be validated in seconds, even when connectivity fails.

What we built

• Members and dues

  Multi-club member registry, automatic debit and multiple payment methods, with e-invoicing and accounting integration.

• Ticketing

  Online sales with exact capacity, numbered seats and dynamic QR tickets, designed to absorb the rush when sales open.

• FaceID access

  Identity validation with liveness detection and national ID registry checks, integrated with stadium turnstiles for paperless entry.

• Offline operation

  Turnstiles and scanners keep validating from local lists if connectivity drops at the stadium.

• Wallet and perks

  Digital wallet and a fan benefits network with partner merchants, inside the members app.

• Multi-tenant

  Each club's data is isolated in its own schema, on a single platform that ships updates to everyone at once.

Scaling for match day

In 2023 we moved the platform to Kubernetes on AWS. The API now scales on its own: during a top-division match with 29,036 entries it went from 10 to 37 instances with no manual intervention, served 3.3 million requests in just over four hours with 99.999% successful responses, and the database never went above 23% CPU.

During the most demanding ticket sale openings the platform went past 74,000 requests per minute (over 1,200 per second) with more than 120 API instances running in parallel.

• Exact capacity under a rush

  We replaced the capacity check with an atomic counter in the database. Load tests with 6,519 simultaneous redemptions: zero overselling, errors from 638 to 0 and database CPU from 95% to 56%.

• Autoscaling that reacts in time

  We redesigned health checks so new instances come into service under load: from 20 to 90 ready instances, p95 from 19.8 s to 5.2 s and 4x throughput.

• Database connections

  We added a per-node connection pooler: from 660 to 199 connections in the same rush, with no out-of-memory kills and the same latency.

• Fewer queries per request

  We optimized tenant switching between clubs: the busiest screens went from 136 to 45 queries per request.

• PostgreSQL 13 → 18

  We upgraded a 70 GB database with more than 42,000 tables in 56 minutes of total downtime. The entry scanner query now plans 5.7x faster.

• Queues that scale on demand

  Background workers scale on queue size and latency instead of CPU, draining spikes of thousands of pending jobs.

The journey

1. 2019

   AccessFan is born

   First version to digitize fans' access to the stadium.

2. 2020 – 2022

   Multi-club platform

   API and web app for member management, online payments and the first QR tickets.

3. 2023

   FaceID, offline mode and Kubernetes

   Facial recognition with liveness detection, scanners that work offline and a move to Kubernetes with autoscaling.

4. 2024

   Identity and invoicing

   National ID registry validation, e-invoicing and integration with access control hardware.

5. 2025

   Global Fan

   Digital wallet, benefits network, numbered seating and the rebrand from AccessFan to Global Fan.

6. 2026

   Ready for the next scale

   Rails 8, PostgreSQL 18, connection pooling and demand-based queue autoscaling.

Tech stack

• Ruby on Rails
• GraphQL
• Next.js
• React
• PostgreSQL
• PgBouncer
• Redis
• Sidekiq
• AWS
• Kubernetes (EKS)
• Karpenter
• KEDA
• AWS Rekognition
• Cloudflare
• Prometheus
• Grafana
• New Relic
• GitLab CI