Skip to content
All case studies
ArchitectureHospitality technology

How a restaurant booking platform handled 5x its peak load on Amazon EC2

A restaurant reservation and pre-order platform in Abuja moved from Azure to AWS. It now handles about 6,000 concurrent requests instead of 1,200, at about 25% lower monthly cost, after a 25-minute cutover with no customer-facing incident.

ClientRestaurant reservation platform, Abuja
DurationLive in production
RegionAWS
CategoryArchitecture
Restaurant bookingsHospitality technology
5xPeak capacity: about 6,000 concurrent requests, up from 1,200
-25%Monthly infrastructure cost, now tied to usage
WeeklyReleases, up from monthly
25 minCutover, with no customer-facing incident
THE PROBLEM

The problem.

Our client is a restaurant reservation and pre-order platform in Abuja. Diners use it to book tables and order ahead, and restaurants use it to manage bookings and prepare orders. Traffic peaks sharply around lunch and dinner.

The platform ran on Azure, on hosting with a fixed monthly cost. It was built for steady load, but the company’s traffic arrives in bursts at peak dining hours. The engine handled about 1,200 concurrent requests, so growth was capped by peak-hour capacity.

Changes were slow too. The team shipped once a month, and a change took about seven days to get approved. Spend had no link to actual usage. The company needed a platform that scales with peak demand, costs less to run and lets a small team ship faster. Its customers book meals in real time, so the move could not disrupt them.

THE APPROACH

What we built.

01

Five milestones

We ran the migration in five milestones: discovery and assessment, design approval, staging with load testing, production go-live, and a hypercare period that ended in handover.

02

From the edge inwards

Amazon CloudFront serves traffic on the company’s own domain, with AWS WAF filtering requests first. An Application Load Balancer in public subnets accepts HTTPS traffic only from CloudFront. Amazon EC2 instances in an Auto Scaling group, in private subnets, add and remove capacity through the day as demand changes. Amazon RDS for PostgreSQL runs Multi-AZ for automatic failover.

03

Encrypted and governed

All traffic is encrypted in transit. CloudFront requires TLS 1.2 or later, the load balancer uses a TLS 1.3 policy with certificates from AWS Certificate Manager, and the database rejects unencrypted connections. Accounts use AWS Organizations and AWS Control Tower. Engineers sign in through AWS IAM Identity Center with read-only access by default, and only the people building the platform get deploy access. The root account has MFA, AWS CloudTrail logs every Region to a dedicated bucket, and Amazon CloudWatch alarms watch the platform.

04

Reviewed and recoverable

AWS CloudFormation defines the whole environment, so every change is reviewed before it is deployed. AI coding assistance helped write the templates, and AI code review checked pull requests between environments. We designed the platform for a recovery time of one hour or less and a recovery point of 15 minutes or less, within a single Region.

05

A change to the organisation

An executive sponsor chaired a fortnightly steering call on risk, budget and the go or no-go decision for cutover. Legal reviewed how customer and payment data would be handled on AWS and updated its terms before cutover. Finance moved from fixed hosting costs to usage-based budgets, backed by cost allocation tags, budget alerts and a monthly review. We trained the engineering team and helped set up an on-call rota. The company told its customers about the cutover window in advance and paused migration work during peak dining hours.

STACK

AWS services in this engagement

Amazon EC2Amazon EC2 Auto ScalingAmazon RDS for PostgreSQLAmazon CloudFrontAWS WAFApplication Load BalancerAmazon VPCAWS Certificate ManagerAWS CloudFormationAWS OrganizationsAWS Control TowerAWS IAM Identity CenterAWS CloudTrailAmazon CloudWatch
THE OUTCOME

The results.

The platform now handles about 6,000 concurrent requests, up from about 1,200: five times the old limit. Monthly infrastructure cost is about 25% lower, and it now follows usage. The team ships weekly instead of monthly, and a change takes about two days to approve, down from about seven.

The cutover took 25 minutes, as planned, with no incident that customers could see.

What we learned: most of the risk in this project sat outside the infrastructure. Legal, finance and the on-call rota all had to change before cutover, and the move from fixed to usage-based spending needed finance involved early. Pausing migration work at lunch and dinner kept us out of the company’s busiest hours. On migrations now, we put the non-technical workstreams on the plan from the first week.

WANT SOMETHING SIMILAR?

Tell us what you're trying to ship.

A 30-minute scoping call with the engineers who would do the work.