How a payroll software company cut month-end processing by 44% with AWS Lambda
A payroll and HR software company in Abuja moved month-end payroll from Heroku to a serverless design on AWS. A payroll run now takes 25 minutes instead of 45, and the system handled 750 concurrent payroll tasks in testing instead of 100.
The problem.
Our client is a payroll and HR software company in Abuja. Its cloud platform helps small and medium-sized businesses manage employees, leave approvals and appraisals, and run payroll with statutory deductions and bank payments. Most of its customers run payroll in the same few days each month.
The company ran its month-end payroll processing on Heroku. The application resources stayed provisioned around the clock, about 720 hours a month, even though payroll work is packed into a few days at month end. The company paid for capacity that sat mostly idle.
The setup also struggled at the peak. When many customer businesses process salaries at once, a payroll run took 45 minutes against a target of 30, and the system handled 100 concurrent payroll tasks against a target of 500.
Left alone, spending on idle infrastructure would rise as the customer base grew. Worse, payroll could run late at month end, which is the moment customers depend on the company most.
What we built.
Event-driven and serverless
We assessed the existing payroll workload first, then designed an event-driven, serverless architecture that scales with month-end demand instead of holding capacity all year. We moved the run in under ten weeks.
From the edge to AWS Lambda
A request enters at the edge. Amazon Route 53 handles DNS, and Amazon CloudFront with AWS WAF serves the web frontend from Amazon S3 and routes API traffic. AWS WAF filters requests before they reach the application. Amazon API Gateway then invokes AWS Lambda functions for the API and for payroll processing. We chose Lambda because it runs only while payroll is processing. The functions run in private subnets across two Availability Zones, with concurrency controls sized for the month-end spike.
Data and recovery
Data sits in Amazon Aurora PostgreSQL, with a primary and a standby in separate Availability Zones and automatic failover. HR documents go to Amazon S3. We designed the service for a recovery time of one hour and a recovery point of 30 minutes.
Canary releases
Every change goes through a delivery pipeline. AWS CodePipeline and AWS CodeBuild build and test each change from GitHub. AWS CodeDeploy releases Lambda updates as canary deployments, so a new version reaches a small share of traffic first. AWS CloudFormation defines the infrastructure, and AI coding assistance helped us write the templates.
Proved at peak before go-live
Amazon CloudWatch metrics and alarms watch Lambda concurrency, errors and throttling. Before deployment, we ran load and stress tests with simulated payroll workloads, so we proved the design at realistic peak volumes before real payroll touched it.
AWS services in this engagement
The results.
A payroll run now takes 25 minutes, down from 45. That is 44% faster and beats the 30-minute target. We compared equivalent month-end workloads before and after, using application logs and Amazon CloudWatch metrics.
The system handled 750 concurrent payroll tasks in load and stress tests with simulated payroll workloads. It was 100 before, so capacity is 7.5 times higher and well past the target of 500. Lambda runs only while payroll is processing; before, resources were provisioned about 720 hours a month. The service is designed to recover within one hour and lose at most 30 minutes of data, using Multi-AZ failover.
What we learned: the month-end spike was the whole problem, so we sized the design and the tests around the peak, not an average day. Simulated payroll workloads showed us the limits before real payroll could. On workloads with a sharp peak, we now start from the peak volume and test with simulated load before go-live.
Tell us what you're trying to ship.
A 30-minute scoping call with the engineers who would do the work.