Martin Källström
knowledge / projects

Twingly Live

Twingly Live was a real-time social stream product designed to run alongside live broadcasts and media events, enabling audiences to follow conversations as they unfolded. Built on long-polling technology, it processed millions of events across browsers, achieving significant traffic during major Swedish events—from 80,000 daily visitors during the 2010 Winter Olympics to experimental loads exceeding 500,000. The product became a vehicle for exploring the emerging "real-time web" paradigm of the late 2000s, and its story is defined less by scale achieved than by the engineering discipline of knowing when not to scale.

Real-time streaming for events

Twingly Live ran alongside broadcast media to enhance the social experience—allowing viewers to see live blog commentary, chat, and community reactions in real time. ▶ 12:00 The product positioned Twingly to capitalize on the emerging interest in real-time web technology that dominated tech conversations around 2009–2010.

In late 2009, Twingly partnered with Vattenfall on a sponsored real-time stream covering the Copenhagen climate conference on dn.se, ▶ 1:04 demonstrating early enterprise use cases for the technology.

Technical approach: long polling at scale

Twingly Live relied on long polling—a technique Martin described as "a set of hacks adapted for different browsers" to maintain persistent connections across platforms. ▶ 40:55 The approach was pragmatic rather than elegant: browser compatibility required accommodating different networking behaviors, but the technique proved effective for handling sustained traffic and real-time updates.

The Olympics and beyond: capacity testing

During the 2010 Winter Olympics and Melodifestivalen, Twingly Live achieved approximately 80,000 daily visitors—a milestone the team celebrated. ▶ 40:29 The platform demonstrated it could handle real event-driven spikes at meaningful scale.

Following the Olympics, Aftonbladet began load testing by introducing 10x the traffic—pushing the system to around 500,000 daily visitors. ▶ 40:29 This became a proof point that the architecture could theoretically scale, but it also revealed an uncomfortable truth about production deployment.

Declining Melodifestivalen: knowing when not to scale

When Aftonbladet wanted to place Twingly Live on their homepage during Melodifestivalen, the opportunity seemed obvious—massive visibility, proven ability to handle 6x the Olympic load. Martin declined.

The reason was unambiguous: "It's too much work in too short a time. I don't want to do it in a week because then we have zero time to test after it's finished building before it needs to go into production." ▶ 43:03 Horizontal scaling of a long-polling architecture required fundamental system redesign. Running untested infrastructure under production load was a different category of risk than stress testing.

This decision reflects an engineering philosophy that separates theoretical capacity from operational confidence. The ability to test matters more than the ability to theoretically scale. It's the story of a company disciplined enough to turn down publicity in service of reliability.

Worth remembering