01 · Peak-shaped capacity
The architecture matched short, high-demand campaign windows instead of keeping fixed capacity sized for rare peaks.
Customer work · Media
ABP Live served 2.08 million concurrent requests at 100% uptime on AWS
ABP Live needed to absorb a short campaign surge without paying for peak infrastructure throughout the year. BluePi built a serverless request path with Amazon API Gateway, AWS Lambda, DynamoDB, CloudWatch, and SNS.
Serverless scale for ABP Live campaign demand
ABP Live expected campaign traffic to reach up to 2 million concurrent requests. BluePi designed an AWS serverless path using API Gateway, Lambda, DynamoDB, CloudWatch, and SNS so request handling, storage, monitoring, and event notification could scale with demand.
02 · Complete request boundary
API entry, execution, data access, limits, latency, and monitoring were handled as one scale path.
03 · Live-event observability
CloudWatch and SNS gave operators visibility into request behavior and conditions that needed attention during the event.
A reusable AWS path for sharp request peaks
Requests entered through API Gateway, Lambda handled execution, DynamoDB supported data access, and CloudWatch with SNS monitored behavior and notified the team. The path handled 2.08 million concurrent requests with 100 percent uptime and reduced campaign infrastructure cost from $530 to $15.
Design for the surge profile
The architecture matched short, infrequent traffic peaks instead of carrying fixed capacity sized for the maximum all year.
Test the complete request path
API entry, execution, data access, limits, latency, and monitoring were treated as one scale boundary.
Make scale observable
CloudWatch and SNS gave operators evidence about request behavior and conditions that required attention during a live event.
Where this pattern fits
This serverless pattern fits any data or AI service that faces sharp workload peaks and needs measured scale, clear operating visibility, and controlled cost.
Case details
Open a section to review the customer problem, implementation, business change, and architecture.
01The starting point
ABP Live expected campaign traffic to surge to two million concurrent requests within short windows. Conventional scaling sized for that peak would sit idle and expensive for the rest of the year, and the platform still had to scale by itself for the next event.
- Scalability: The existing infrastructure could not handle the anticipated surge of 2 million concurrent requests.
- Cost efficiency: Traditional scaling was too expensive for infrequent, short traffic spikes.
- Agility: The platform needed to scale automatically for future high-demand events.
02System delivered
BluePi built a serverless request path on AWS. Amazon API Gateway receives every call, AWS Lambda runs the application code with no servers to manage, and Amazon DynamoDB stores campaign data at whatever volume the traffic demands. Amazon CloudWatch tracks performance and resource use, and Amazon SNS carries real-time notifications for event triggers and scaling actions.
- AWS API Gateway: A single entry point manages all incoming API requests.
- AWS Lambda: Runs the application code with no servers to manage.
- AWS DynamoDB: Stores campaign data in a NoSQL database that scales with traffic.
- AWS CloudWatch: Monitors application performance and resource use.
- AWS SNS: Sends real-time notifications for event triggers and scaling actions.
03Outcomes
The architecture served 2.08 million concurrent requests at 100 percent uptime during high-demand events. Campaign infrastructure cost fell from $530 to $15, and the team ships features without server management work.
- Peak load handled: The serverless architecture handled 2.08 million concurrent requests with 100% uptime.
- Cost savings: Campaign cost fell from $530 to $15.
- Improved agility: The team develops and deploys new features without server management overhead.
- Reduced maintenance: No servers to provision, manage, or maintain.
- Lower total cost of ownership (TCO): Costs for server management, software licenses, and infrastructure maintenance went away.
04Constraints that shaped the design
The traffic pattern ruled out provisioned capacity: rare, short spikes separated by long quiet periods. Every component had to scale on demand and bill only for actual use. The path also had to stay simple enough for the team to operate without a dedicated infrastructure function.
05Evaluation and live use
The platform was judged on the conditions that matter for a live campaign: concurrent-request capacity, availability through the surge, and cost per campaign. CloudWatch metrics gave the team a continuous view of performance and resource consumption during each event.
06What changed for campaign delivery
Capacity planning stopped being a pre-campaign project. The team develops and deploys features without provisioning work, and per-campaign infrastructure spending dropped by two orders of magnitude, which changed which campaigns were worth running.