Event-Driven Ticketing Platform — Billions of Events at Scale

When I joined, ticket sales ran on a monolith. A flash on-sale puts tens of thousands of requests a minute through it inside a ten-minute window, content updates propagated synchronously, and a deploy took 45 minutes. That shape caps both throughput and release cadence no matter how much you tune it, so the work was to change the shape rather than the settings.

I ripped the monolith apart into event-driven microservices connected through EventBridge and SQS. I built the content ingestion service from scratch, capturing real-time webhooks from Contentful and Umbraco, normalizes them, and fans out events to downstream consumers using a transactional outbox pattern. 9 specialized content handlers, dual-trigger event emission, and exactly-once delivery guarantees. The deployment orchestrator drove GitHub Actions workflows so that when a brand config changed in the CMS, all dependent repos deployed automatically across 4 AWS regions. No more manual coordination across 40+ brand websites.

The catalogue aggregation layer was where it got interesting. It was hitting DynamoDB throttling hard during peak on-sale windows. The fix was consolidating N performance-level schedules into 1 show-level schedule, which cut throttling by 100x. The service processes billions of events annually, feeding a Typesense search layer that returns results in under 100ms across millions of catalogue items. Blue-green search infrastructure means zero-downtime schema migrations.

On the edge layer, I built a Cloudflare Workers service routing traffic for 15+ Broadway theatre websites. 17 sequential filters processing every request, handling maintenance windows, Apple Pay verification, dynamic redirects, and per-venue configuration. The whole platform now serves 40+ brands across 4 regions. Deploy time went from 45 minutes to under 5. Throttling at peak dropped 100x. The 3am pages still happen, but now its because of actual edge cases, not infrastructure falling apart.