Tomcat Events — Event Ticketing Platform

What Was Built

Tomcat Events is a fully serverless event registration and ticketing platform built on AWS, designed to handle high-concurrency ticket sales without the cost or complexity of managing persistent servers. The platform features event discovery, attendee registration, and automated confirmation workflows, all triggered on demand through Lambda-backed API endpoints. Its static frontend assets are hosted on Amazon S3 and delivered globally through Amazon CloudFront with Origin Access Control (OAC) enforced, ensuring the raw S3 bucket is never directly accessible. Transport security is enforced end-to-end using custom SSL/TLS certificates managed by AWS Certificate Manager (ACM). The backend registration pipeline includes an automated ID parsing microservice that extracts and validates attendee information from submitted documents, reducing manual data entry overhead for event organizers. Attendance data, user records, and registration payloads are processed by AWS Lambda functions and persisted directly into Amazon DynamoDB for reporting. Operational visibility and system health are monitored through proactive Amazon CloudWatch alarms configured to track Lambda execution error rates, API Gateway 5xx response codes, and DynamoDB throughput throttling events.

Why Was It Built

Ticketing and event registration platforms experience extreme traffic volatility, switching from complete inactivity to thousands of concurrent requests the moment ticket sales open. Traditional server architectures often fail under these sudden bursts unless expensive, over-provisioned infrastructure is maintained continuously. Tomcat Events was built to eliminate these financial and operational inefficiencies by implementing a cloud-native, zero-idle-cost platform that scales automatically from zero to high concurrency. The platform was also developed as part of a cloud computing program milestone, serving as a practical demonstration of serverless microservice design, automated document processing workflows, robust CloudWatch operational monitoring, and secure static web hosting on AWS.

How It Works

When an attendee visits the platform, the client browser fetches the static single-page interface from the nearest Amazon CloudFront edge location, achieving fast sub-50ms delivery while keeping the underlying S3 origin bucket private via Origin Access Control. User interactions, such as browsing events or submitting a ticket registration, trigger HTTPS REST requests to Amazon API Gateway. API Gateway routes the payload to specific AWS Lambda microservices running a Python execution environment. For registration workflows involving identification verification, the dedicated Lambda function receives the document payload, executes automated parsing and validation logic, and writes the structured attendee profile directly into Amazon DynamoDB. Concurrently, CloudWatch collects performance metrics, log groups, and error indicators across every layer of the architecture, automatically firing alerts if latency thresholds or operational failure rates are exceeded.

What Broke and How Did I Fix It

During system testing and infrastructure deployment, several critical architectural hurdles were encountered and resolved. A major initial issue involved permission errors and HTTP 403 Access Denied responses when accessing static web assets through CloudFront. This was caused by legacy S3 bucket policies expecting an Origin Access Identity (OAI) rather than the newer Origin Access Control (OAC) standard, which was fixed by updating the CloudFront distribution to use OAC, modifying the S3 bucket policy to explicitly restrict `s3:GetObject` access strictly to the CloudFront Service Principal, and disabling public access. Additionally, early Lambda executions for document parsing experienced timeouts when processing larger payload sizes, which was resolved by tuning the Lambda function memory allocation and optimizing the memory-to-CPU ratio to accelerate parsing tasks. Finally, initial DynamoDB write operations during registration spikes triggered intermittent write throttling errors, which was addressed by configuring dynamic auto-scaling policies on the DynamoDB table throughput metrics and establishing CloudWatch alarm thresholds to proactively catch throttled requests before impacting end users.