High-traffic campaign platform
A campaign and user-participation platform with access peaks concentrated into short windows and non-negotiable campaign deadlines.
Anonymized case study: client names, infrastructure data, and sensitive details have been omitted for confidentiality.
Context
A digital platform for campaigns and user participation. Its load pattern is the opposite of steady traffic: long quiet periods followed by sharp peaks the moment a campaign goes live.
Challenge
A campaign has a date and a time. If the platform falls over at the peak, there is no second chance. The deadline belongs to the business, not to engineering. The system has to absorb the peak or degrade in a controlled way.
My role
Senior Software Engineer, focused on backend performance, Node.js services, database, and incident response.
Responsibilities
- Backend performance under concentrated load.
- Node.js services.
- MongoDB queries and modeling.
- Monitoring, uptime, and incident response.
Constraints
- Non-negotiable, publicly announced campaign deadlines.
- Highly irregular load: sizing for the peak is expensive, sizing for the average is failure.
- A failure during a campaign is visible to end users and to the client.
Architecture
- Caching on the hottest read paths, so the peak does not reach the database in full.
- Review of the queries on the critical participation path.
- Routing and supervising the Node.js processes.
- Monitoring with particular attention to campaign windows.
Main technical decisions
Optimize the critical read path before scaling infrastructure.
Why
Throwing hardware at a bad query multiplies cost and only postpones the problem. The participation path is short and well understood, and it could be made cheap.
Trade-offs
- Optimization work is slower than spinning up instances.
- Caching introduces invalidation, which has to be handled explicitly.
- The gain, however, persists after the peak is over.
Implementation
- Performance work on Node.js services.
- Query and index review in MongoDB.
- A caching layer on the most-hit endpoints.
Production concerns
- Real-time monitoring during campaign windows.
- Incident response with a campaign live.
- Uptime tracked as a business metric, not merely a technical one.
Results
- Sustained platform operation through campaign peaks.
- Reduced the load reaching the database on the most-accessed endpoints.
- Made campaign-time incidents diagnosable from monitoring rather than trial and error.
Stack
- Node.js
- MongoDB
- NGINX
- Redis
- Linux