La tristement célèbre baleine de Twitter était absente le jour de l'élection présidentielle américaine, même lorsque les serveurs de Twitter traitaient 327 452 tweets par minute, d'après Mazen Rawashdeh, vice président de l'Infrastructure Operations Engineering chez Twitter. Au total, il y avait 31 millions de tweets liés aux élections sur la journée, et les pics périodiques de trafic continuaient — pour atteindre jusqu'à 15 107 tweets par seconde. A titre de comparaison, le soir de l'élection de 2008, Twitter a culminé à 229 tweets par seconde.
Rawashdeh note que Twitter a constaté un changement dans le mode d'utilisation au cours de la dernière année en allant de pics de courte durée (par exemple liés au douze coups de minuit un soir de réveillon du nouvel an, ou à l'annonce de la grossesse d'une célébrité) vers des pics de trafic plus soutenus durant plusieurs heures. Ce fut le cas, par exemple, lors de la cérémonie de clôture des jeux olympiques, la finale de la NBA, et maintenant avec l'élection.
Une des raisons du succès de Twitter à maintenir ce niveau de trafic était dû à plusieurs changements dans l'infrastructure de la société, y compris, comme précédemment rapporté par InfoQ, une migration progressive de Ruby vers un ensemble de services écrits dans un mélange de Java et Scala tournant dans une JVM.
La modification la plus récemment signalée concerne les clients mobiles de Twitter. Rawashdeh écrit :
Dans le cadre de notre démarche actuelle d'écarter Ruby, nous avons reconfiguré le service pour que le trafic mobile atterrisse sur une JVM, évitant tout Ruby.
Twitter était connu à une époque comme étant la plus grande boutique Ruby on Rails au monde, et a beaucoup investit dans Ruby, en allant jusqu'à développer son propre garbage collector générationnel Kiji pour Ruby, qui contrairement au garbage collector standard, répartit les objets en générations, et sur la plupart des cycles de ramassage, placera uniquement les objets d'un sous-ensemble de générations dans le white set initial (NDT les objets candidats à une libération de la mémoire, aussi appelé condemned set).
En 2010, cependant, la firme a annoncé qu'elle changeait le cap de certains axes de développement. Pour le front-end l'entreprise a suivi la tendance HTML5 de rendu dans le navigateur à l'aide de JavaScript, faisant perdre sa valeur ajoutée au système de templating de Rails pour la construction des pages web. Ensuite, citant à la fois les performances et l'encapsulation comme moteurs, l'équipe d'ingénieurs a réécrit la file de messages du back-end et le moteur de stockage de tweets en Scala.
Toujours en 2010, l'équipe en charge du moteur de recherche à Twitter a commencé à réécrire le moteur, en changeant le stockage de MySQL vers une version construite à base de Lucene. Puis, en 2011, l'équipe d'ingénieurs a annoncé qu'elle avait remplacé le Ruby on Rails en frontal pour la recherche par un serveur Java qu'ils ont appelé Blender. Cela s'est traduit par une chute de 3 fois moins de latences pour la recherche.
En raison de ces changements, le système de Twitter a fonctionné sans problèmes. «L'essentiel: peu importe quand, où et comment les gens utilisent Twitter, nous devons rester accessibles 24/7, partout dans le monde», a écrit Rawashdeh. «Nous travaillons d'arrache-pied pour offrir cette vision.»