Brian Degenhardt discusses lessons that Twitter learned managing a high rate of change and complexity, and how those can be applied anywhere.
Raffi Krikorian discusses the software engineering challenges met re-architecting Twitter and the cultural change impact that came with it.
Jeremy Cloud discusses SOA at Twitter, approaches taken for maintaining high levels of concurrency, and briefly touches on some functional design patterns used to manage code complexity.
Raffi Krikorian explains the architecture used by Twitter to deal with thousands of events per sec - tweets, social graph mutations, and direct messages-.
Johan Oskarsson explains how Twitter is using Zipkin to trace a pages in order to see their execution path and to determine the time spent for loading for performance monitoring and analysis.
Dmitriy Ryaboy shares some of the lessons learned scaling Twitter’s analytics infrastructure: Data loves a schema, Make data sources discoverable, and Make costs visible.
Nathan Marz introduces Twitter Storm, outlining its architecture and use cases, and takes a look at future features to be made available.
Raffi Krikorian details Twitter’s timeline architecture, its “write path” and “read path”, making it possible to deliver 300k tweets/sec.
Nathan Marz discusses Storm concepts –streams, spouts, bolts, topologies-, explaining how to use Storms’ Clojure DSL for real-time stream processing, distributed RPS and continuous computations.
Arya Asemanfar presents Twitter’s timeline architecture, the entire sequence of steps a tweet goes through until it reaches the timeline of each user following the person who tweeted.
Attila Szegedi shares lessons learned tuning the JVM at Twitter, spending most of his talk discussing memory tuning, CPU usage tuning, and lock contention tuning.
Nathan Marz explain Storm, a distributed fault-tolerant and real-time computational system currently used by Twitter to keep statistics on user clicks for every URL and domain.