În primele zile ale Instagram, fiecare inginer de infrastructură IG trebuia practic să memoreze ID-ul de utilizator al @justinbieber... pentru că de fiecare dată când Bieber posta, întâmpinam probleme cheie pe CassandraDB și Instagram. 🥵🥵 Mai multe servere web ar încerca să recupereze aceleași date din cache (de exemplu, numărul de like-uri), ar lovi un cache ratat și toate ar inunda baza de date, declanșând o problemă clasică de turmă de tunet. Oncalls aveau literalmente un runbook: dacă se declanșa o alertă, verificați dacă era ID-ul de utilizator al lui bieber, apoi rulați o operațiune de killswitch... Servirea datelor fierbinți este dificilă, servirea resurselor accesate la nivel global, cum ar fi contoarele, este dificilă. Dar stivele de infrastructură precum @Aptos sunt construite pentru a face față exact acestui lucru, agregatoarele și Block-STM rezolvând problemele de coordonare de bază în mod nativ. Și cu @shelbyserves optimizarea și mai mult a performanței serviciilor de date și permițând o nouă economie a datelor, sunt încântat să văd că Shelby + Aptos ocupă un loc important în perturbarea afacerii cloud în viitor. (P.S. O grămadă de ingineri care au lucrat la scalarea Instagram s-au alăturat mai târziu unui proiect numit Libra/Diem și, în cele din urmă, au ajuns la @AptosLabs. Unul dintre ei, @zekun000, este șeful Blockchain la Aptos și construiește protocolul Shelby)