TicketSauce

TicketSauce operates a cloud-based event ticketing and management platform serving event organizers across North America — real-time ticket sales, payment processing, and attendee management. The defining characteristic of the workload is its traffic profile: when a popular event goes on sale, demand spikes sharply, and every minute of degraded service is lost revenue.

The platform ran on Rackspace private cloud with statically provisioned web, application, and database servers. There was no dynamic scaling, so peak on-sale events — exactly the moments that mattered most — brought frequent downtime. Static allocation forced a standing trade-off between over-provisioning (paying for idle capacity) and under-provisioning (failing at peak). Rackspace’s pricing was fixed regardless of utilization; provisioning new infrastructure took days to weeks; scaling existing capacity took hours of manual work. Left unaddressed, the risk was degraded customer experience and client loss to competitors. TicketSauce needed elastic, automated, cost-aligned infrastructure that could absorb on-sale spikes without manual intervention.

Assess: discovery, dependencies, and the Well-Architected baseline

The engagement opened with a structured Assess phase: a Well-Architected Review in January 2024 and discovery across the existing Rackspace infrastructure, application dependencies, and performance requirements. This was a migration with a head start — TicketSauce’s team had begun writing Terraform for AWS but could not get the SaaS platform deployed to production: the codebase carried broken module dependencies, legacy NGINX and Lambda resources, and entangled IAM policies. Discovery findings drove the central architectural decision: containerize on Amazon ECS with Amazon RDS and Amazon ElastiCache rather than attempt a simple lift-and-shift, and remediate the existing infrastructure code rather than discard it. Scope was refined with the customer through successive statement-of-work iterations before build began.

Mobilize: the Terraform and Terragrunt build-out

The AWS environment was defined entirely as code in Terraform with Terragrunt managing remote state and module dependencies. The VPC module was hardened to least-privilege security groups with VPC Flow Logs enabled and unused endpoints removed; the ECS module was cleaned of legacy NGINX and Lambda resources; ALB and target-group, Secrets Manager, Systems Manager, and WAF modules completed the estate. A dedicated three-account structure — management with consolidated billing, production, and staging — separated concerns from day one. Every change flowed through GitLab CI/CD from development through QA/UAT to production, with a disciplined change taxonomy: dependencies mapped first, every change categorized as destructive or non-destructive, non-destructive changes executed first in sandbox and staging, and production applied only through terragrunt plan and applyinside agreed change windows — never through the console.

Migrate and modernize: the four-week execution window

Execution ran 8 April to 7 May 2024. The application was containerized and moved onto Amazon ECS with EC2 capacity providers, replacing manually managed servers with an orchestrated, auto-scaling container fleet fed from Amazon ECR. The database was migrated to Amazon RDS, Multi-AZ, using AWS DMSfor the cutover — converting a single fixed-capacity database server into a managed, failover-ready engine with a synchronous standby in a second Availability Zone. Auto Scalingwas wired directly to on-sale traffic patterns, so capacity now expands in seconds instead of hours. Session state moved onto Amazon ElastiCache (Redis), keeping the application tier stateless. At the edge, Cloudflare CDN/WAF was layered with AWS WAF and AWS Global Accelerator. Cutover followed a pre-defined plan: load testing against the new environment, staged production deployment in mid-April, UAT verification, a knowledge-transfer and customer-validation session, and post-migration monitoring through completion on 7 May — after which the Rackspace source environment was exited. One concrete engineering example from delivery: IAM policies found tightly coupled to legacy NGINX components were decoupled and rebuilt to least-privilege best practice before production cutover.

Governance and delivery discipline

The project ran on a weekly status cadence with explicit status keys for budget, resources, timeline, and scope, hours-consumed tracking, and a risk register with owners and fixes. A Gantt plan sequenced the workstreams — planning, VPC/WAF modules, ELB/ECS modules, supporting modules, then testing and validation — against milestones for development deployment in early April, production deployment on 16 April, and knowledge transfer with customer validation on 19 April. A kickoff deck documented objectives, outcomes, and the risk register the engagement was managed against, and the engagement closed with documentation, cleanup, and a formal knowledge-transfer session.

The January 2024 Well-Architected Review anchored the design, and the delivered estate evidences all six pillars. Operational excellence: everything defined as Terraform/Terragrunt code, promoted through GitLab CI/CD, with Amazon CloudWatch monitoring and alerting configured as part of post-migration validation. Security: defense-in-depth for a payment-processing platform — dual WAF layers (Cloudflare plus AWS WAF), least-privilege security groups with VPC Flow Logs, AWS KMS encryption, Secrets Manager for credentials, Systems Manager for operational access, and CloudTrail logging, with the IAM estate rebuilt to least privilege. Reliability: RDS Multi-AZ failover, stateless ECS tasks behind an ALB with Auto Scaling, session state externalized to ElastiCache, and load testing before cutover. Performance efficiency: per-service container scaling for on-sale bursts, Redis caching under peak load, and AWS Global Accelerator routing at the edge. Cost optimization: fixed private-cloud pricing converted to utilization-aligned pay-as-you-go — the realized ~30% IT-cost reduction. Sustainability: elastic capacity that scales with real demand in place of statically over-provisioned servers.