Nei primi giorni di Instagram, praticamente tutti gli ingegneri dell'infrastruttura IG dovevano memorizzare l'ID utente di @justinbieber... perché ogni volta che Bieber postava, ci trovavamo ad affrontare problemi di chiavi calde su CassandraDB e Instagram si bloccava. 🥵🥵 Molti server web cercavano di recuperare gli stessi dati dalla cache (ad es., numero di like), colpivano un cache miss e inondavano tutti il database, attivando un classico problema di thundering herd. Gli oncall avevano letteralmente un runbook: se scattava un allerta, controlla se era l'ID utente di Bieber, poi esegui qualche operazione di killswitch... Servire dati caldi è difficile, servire risorse globalmente accessibili come i contatori è difficile. Ma stack infrastrutturali come @Aptos sono costruiti per gestire esattamente questo, con Aggregatori e Block-STM che risolvono nativamente i problemi di coordinazione fondamentali. E con @shelbyserves che ottimizza ulteriormente le prestazioni di servizio dei dati e abilita una nuova economia dei dati, sono entusiasta di vedere Shelby + Aptos prendere un posto importante nel disruptare il business del cloud in futuro. (P.S. Un gruppo di ingegneri che ha lavorato per scalare Instagram si è poi unito a un progetto chiamato Libra/Diem, e alla fine è approdato a @AptosLabs. Uno di loro, @zekun000, è il Responsabile Blockchain di Aptos e sta costruendo il protocollo Shelby)