Rawashdeh 氏によれば，昨年あたりから Twitter の利用パターンが短時間のスパイク (例えば大晦日の深夜の鐘や有名人の妊娠発表に関するもの) から，数時間に渡ってピークが続くような，より持続的なものに変わってきているという。オリンピックの閉会式やNBA ファイナル，そして今回の選挙などがこのパターンだ。
Twitter がこれ程のトラフィックレベルを維持できた理由のひとつには，同社が実施してきた一連のインフラストラクチャ変更がある。例えばInfoQ が以前レポートしたように，Ruby から Java と Scala で記述された JVM 上で動作するサービスへの段階的なシフトなどもそれに含まれる。
最近報告された変更は，Twitter のモバイルクライアントに関するものだった。Rawashdeh 氏によれば，
Ruby からの継続的移行の一環として，当社のモバイルクライアントからのトラフィックが Ruby スタックを完全に回避して，Java 仮想マシン(JVM)スタック側に送られるように，サービス設定の変更を行いました。
Twitter は，かつては世界最大の Ruby on Rails ショップと考えられていた。Ruby スタックに対する投資額も非常に大きく，Kiji という独自の世代別ガベージコレクタの開発さえ行っている。これは Ruby の標準コレクタとは違ってオブジェクトを世代別に分離し，大部分のサイクルでは世代の一部のオブジェクトのみを最初のホワイト (使用済) セットとするものだ。
しかし 2010年になって，同社は開発の重点を部分的にシフトすると発表した。フロントエンドでは HTML5 のトレンドに従って，ブラウザベースの JavaScript によるレンダリングコードへとシフトした。それによって Rails の Web ページ構築モデルによるメリットの多くが失われることになったのだ。その後にはパフォーマンスとコードのカプセル化の両方を理由として，バックエンドのメッセージキューとツィートストレージエンジンがいずれも Scala で書き直された。
同じく 2010年，Twitter の検索チームも検索エンジンの再構築に着手し， 検索ストレージを MySQL から Lucene 上に構築されたものに変更した。そして 2011年に開発チームが，Ruby on Rails の検索フロントエンドを，同社が Blender と呼ぶ Java サーバにリプレースすることを発表したのだ。これによって検索待ち時間は 1/3 にまで減少した。
このような変更の結果として，Twitter システムは問題なく動作したのだ。"結論：いつでも，どこでも，どのように利用される場合でも，Twitter は変わらず世界中でアクセス可能であることが必要なのです" と Rawashdeh 氏は書いている。"このビジョンを実現するため，私たちは努力しています。"