Penso che la scalabilità significhi davvero avere la capacità di aggiungere capacità aggiungendo componenti (hardware, in genere) senza che nessun componente individuale diventi sempre più carico con l'aumentare della domanda di sistema. In altre parole, in un sistema scalabile non esiste un componente collo di bottiglia che alla fine limiterà le prestazioni e il throughput. Invece, le prestazioni e il throughput restano idealmente costanti o almeno si riducono più lentamente di quanto la domanda sul sistema non cresca.
Hai ragione a tenere a mente concetti come tolleranza agli errori e alta disponibilità (e la loro implementazione tramite replica), ma li vedo più preoccupati di affidabilità rispetto alla scalabilità . Sebbene spesso implementati insieme, sono due cose diverse.
Nell'esempio del grafico, cosa è necessario ridimensionare?
-
È l'accesso al grafico (un gran numero di utenti simultanei)?
-
Per quanto riguarda l'accesso, è l'accesso in scrittura che necessita di ridimensionamento o solo l'accesso in lettura?
-
È la dimensione del grafico stesso (ad esempio un gran numero di nodi come il social graph di Facebook)?
-
E riguardo la complessità? Ogni nodo deve supportare un numero arbitrario di connessioni?
-
Ogni nodo (e quindi il sistema nel suo insieme) deve contenere quantità arbitrariamente grandi di dati?
Queste sono alcune questioni pragmatiche che devono essere affrontate quando si parla di scalabilità. Come la maggior parte delle sfide di progettazione, si tratta in realtà di rompere il problema nelle questioni fondamentali che devono essere affrontate.
Infine, vedo tecniche come la programmazione asincrona che contribuiscono all'efficienza , ma non alla scalabilità. A meno che tu non stia facendo qualcosa di importante come la sostituzione di un algoritmo quadratico con uno lineare, le efficienze da sole non saranno di grande aiuto con la scalabilità (vedi Legge di Amdahl ). Aiuteranno con il costo della scalabilità (un problema molto pragmatico), ma non con il potenziale per questo.