Quando parliamo di sistemi distribuiti di solito uno dei dogmi fondanti è il cosiddetto CAP Theorem, internamente ne abbiamo coniato un altro, per certi versi simile: RTL.

Reliability, Throughput, Latency

Mentre CAP descrive una caratteristica intrinseca del sistema, RTL vuole principalmente descrivere una caratteristica dell’output del sistema, o se vogliamo vederla in un modo diverso di quali sono le aspettative che l’utente può avere e che desidera vengano rispettate.

Come per CAP, Reliability, Throughput e Latency non posso tutte e e tre essere massimizzate contemporaneamente. Devo fare delle scelte e sacrificarne almeno una, o una parte di essa in favore di una delle altre due. Se mi aspetto un sistema altamente responsivo, ergo con Throughput altissimo e Latency bassissima, forse ma forse devo accettare che perdermi per strada qualche pezzo è possibile altrimenti devo sacrificare una delle due a favore della Reliability.

Questo introduce un interessante aspetto sia dal punto di vista architetturale, che di modellazione, che di scelta tecnologica: fare una scelta uniforme e consistente in un sistema distribuito nella maggior parte dei casi non è la strada ideale.

I modelli di cui stiamo discutendo potrebbero avere requisiti, in termini di RTL, radicalmente diversi, ergo le scelte architetturali e tecnologiche di uno potrebbero essere sbagliate per un altro.