Skip to content
abin.th

Platform · Backend & infrastructure owner

Confidential client

Event Management Platform

Registration, operations and admin tooling for a large-scale event platform, built and run across five backend services and supporting ~150K concurrent users at peak.

Client and product names are withheld for confidentiality.

Concurrent users at peak
~150K
Requests per second at peak
~5K
API response time at peak
<200 ms
Backend services
5

Problem

A large event needed a platform that stays fast through 3–4 day event windows, when traffic peaks at ~150K concurrent users and thousands of requests per second.

What I built

  • Five Java / Spring Boot backend services, each in its own repository
  • Backend APIs for registrations, KYC workflows, seat bookings and internal chat
  • A data layer on MySQL and DynamoDB
  • The APIs behind the admin dashboard (Next.js, React, Redux Toolkit, Tailwind CSS), working with the frontend team
  • AWS infrastructure on ECS with Fargate, including autoscaling
  • Separate staging and production environments, and deployments from code to production

Technical highlights

  • Owned the backend services, AWS infrastructure and deployments
  • Sustained <200 ms API responses at ~5K requests per second at peak
  • Ran in production across multiple editions of a recurring event; now leading backend development for the next one
  • Autoscaling container workloads to absorb event-day traffic
  • A staging environment kept separate from production
  • Now being developed into a standalone product

Key decisions

  1. 01

    ECS Fargate with autoscaling

    The client needed the platform to absorb sharp traffic peaks on event days. Fargate let container tasks scale out for the spike and back in afterwards, without servers to manage.

  2. 02

    MySQL and DynamoDB, side by side

    MySQL for relational data like registrations, users and events, where joins and transactions matter. DynamoDB for high-volume lookups that need fast, predictable reads under event-day load.

  3. 03

    Five services instead of one application

    Each service owns a clear domain and can scale, deploy and fail on its own. The hot paths could scale up on event days without touching the rest, and a fault in one service didn't take the platform down.

Hardest problems

  • Keeping responses under 200 ms with ~150K concurrent users and ~5K requests per second at peak
  • Shipping changes safely, without downtime, while the event was live

Architecture

  1. Admin dashboard · Next.js
  2. 5 Spring Boot services
  3. MySQL · DynamoDB
  4. AWS ECS · Fargate · Autoscaling
  5. Staging → Production

Stack

  • Java
  • Spring Boot
  • MySQL
  • DynamoDB
  • Next.js
  • React
  • Redux Toolkit
  • Tailwind CSS
  • AWS ECS
  • Fargate