Ho una divertente storiella su come ho rimediato troppo tardi a problemi di scalabilità in una delle mie comunità, che conta 1,2 milioni di membri.
SkyscraperCity è una delle più grandi, se non la più grande comunità al mondo dedicata all’architettura, all’ambiente urbano e alle strutture metropolitane. Ogni area del mondo con un livello significativo di sviluppo urbano e relative strutture di grandi dimensioni ha la propria sezione. Naturalmente, all’interno vengono condivise un’enorme quantità di immagini, perché, beh, i membri di quella comunità amano davvero, davvero mostrare e raccontare i grattacieli di cui si parla.
Il problema non è emerso dove ci si aspetterebbe.
Il problema non era aver rimandato la scalabilità della gestione delle immagini e degli allegati. Questo sarebbe stato un fattore noto, e la piattaforma era stata progettata per gestirlo.
Il problema si è presentato con la crescita del numero di aree metropolitane distinte e, con ciascuna nuova categoria, sottocategoria, sotto-sotto-sottocategoria basata su continente, nazione, stato e infine città, di cui potevano esserci qualsiasi numero di quartieri. L’architettura informativa della comunità aveva superato la capacità della piattaforma di gestire l’attivazione di ciascuna di queste aree. La piattaforma stava cedendo sotto il peso di tutte quelle categorie e le prestazioni erano rallentate fino a diventare quasi inesistenti. Navigare da una pagina all’altra era doloroso, figuriamoci pubblicare un messaggio!
La piattaforma specifica era una build personalizzata di XenForo più vecchia, basata su alberi di nodi per le categorie; non era progettata per gestire centinaia o migliaia di categorie individuali come parte della struttura. Per il modo in cui era costruita, ogni nodo occupava una buona quantità di risorse, quindi più nodi c’erano in un certo punto, meno stabile era la piattaforma. Da nerd qual sono, ho descritto il problema alla comunità paragonandolo a un episodio particolare di Star Trek: The Next Generation, in cui scoprono che i motori warp stanno facendo buchi nel tessuto dello spazio/tempo un po’ troppo frequentemente, indebolendo lo spazio in un’area molto trafficata.
Le infinite categorie (sotto-sotto-sotto-sottocategorie e così via) stavano causando “danni” alla stabilità della piattaforma nello stesso modo in cui centinaia di motori warp attivati in e intorno a un’area popolare dello spazio causavano il collasso di quell’area.
La soluzione non era dissimile da quella della Federazione, nel senso che si riduce la velocità e si limita il numero di perforazioni. Quindi abbiamo eseguito una revisione approfondita dell’architettura informativa, unito un bel po’ di categorie di livello inferiore e persino alcune di quelle superiori, e il sistema si è stabilizzato.
Naturalmente, questo problema non si presenta con Discourse, poiché Discourse tratta le categorie molto meglio come contenitori di primo livello, piuttosto che come un unico grande albero strutturale. Una rete miceliare o condotti di transwarp, se preferite. Ma questo è sicuramente uno degli esempi più eclatanti che ho di una scalabilità avvenuta troppo tardi, e non esattamente dove ci si aspetterebbe che il colpo arrivasse.
