Designing an Elastic, Container-Based Infrastructure for a Growing Webinar Platform

Context

The client's webinar product was outgrowing the infrastructure it ran on. In-house servers were expensive to maintain and slow to expand; every real burst of demand meant a genuinely slow, costly provisioning cycle. For a product still actively growing, that wasn't just an operational annoyance; it was a real risk to the sustainability of the business model itself.

The project

1. Design the platform's hosting on AWS EC2 from the ground up, using large instances capable of running several concurrent webinar sessions each.
2. Package the webinar service in Docker containers, and adopt the newly announced Docker Swarm to cluster those containers across the EC2 fleet.
3. Build a custom control service (internally, "the master") on top of that cluster: for every webinar, decide which machine should run its container; watch real demand and launch a new EC2 instance whenever the cluster's actual capacity ran low.
4. Handle teardown just as carefully. When a webinar ends, its container is removed, and the master checks whether a machine has gone idle. An idle machine isn't powered off immediately; it's first marked for deletion, a quarantine state that stops any new webinar from being placed on it, and only actually terminated once everything already running on it has finished, avoiding a machine getting shut down mid-webinar.

Our role

• Designing the master control service: placement, scale-up, and safe scale-down logic.
• Integrating Docker Swarm as the clustering layer across the EC2 fleet, a genuinely new, still-maturing tool.
• Designing and building the client's new hosting architecture, replacing in-house servers without disrupting a growing, already-live product.

Technologies

• AWS EC2, large instances running multiple concurrent webinar sessions each.
• Docker, for packaging the webinar service itself.
• Docker Swarm, for clustering containers across the EC2 fleet.
• A custom control service, for demand-driven placement and machine lifecycle management.

Conclusion and lessons learnt

The real shift here wasn't moving to the cloud on its own; plenty of products do that and still run on a fixed-size fleet sized for their worst day. It was treating capacity itself as something the system reasoned about continuously, driven by real demand rather than a number someone picked in advance, that turned a slow, capital-intensive scaling problem into something the infrastructure handled on its own.