← Tutti gli episodi
Copertina di Un cameriere per mille tavoli: l'architettura a eventi
Stagione 35 · Episodio 003

Un cameriere per mille tavoli: l'architettura a eventi

5 settembre 2026 5:35
0:00 5:35

Ciao, e benvenuto nella terza puntata della trentacinquesima stagione. Nella scorsa puntata abbiamo visto il muro che nginx doveva rompere: gestire decine di migliaia di connessioni simultanee, dove il vecchio modello, un lavoratore per connessione, crollava. Oggi vediamo l'idea geniale con cui nginx lo rompe, il cuore della sua efficienza, la parte più bella di tutta la stagione: l'architettura a eventi. Cioè un modo completamente diverso di gestire tantissime connessioni insieme, che permette a pochissimi lavoratori di servirne migliaia, senza mai restare fermi ad aspettare. Oggi capiamo questa idea, con l'immagine del cameriere.

Partiamo dal capire il difetto profondo del vecchio modello, perché è la chiave di tutto. Ricordi il cameriere fermo a ogni tavolo? Il problema non era solo il numero: era che ogni lavoratore, per gran parte del tempo, stava fermo ad aspettare, senza fare nulla. Aspettava che il visitatore lento mandasse i suoi dati; aspettava una risposta; restava bloccato, occupando risorse, senza combinare niente. Nel mondo dei web server, gran parte del tempo di una connessione è tempo di attesa. E il vecchio modello sprecava un lavoratore intero, bloccato, per ogni singola attesa. Diecimila attese significavano diecimila lavoratori bloccati. Lo spreco non era il lavoro, era l'attesa: un lavoratore intero fermo ad aspettare, moltiplicato per migliaia.

Ed ecco l'idea rivoluzionaria di nginx, che voglio farti afferrare bene: non restare mai fermi ad aspettare. nginx usa pochissimi lavoratori, e ognuno di essi, invece di seguirne uno solo, gestisce migliaia di connessioni contemporaneamente. Come? Non aspettando mai su una singola connessione. Il lavoratore di nginx non si mette fermo accanto a una connessione in attesa che succeda qualcosa. Invece, tiene d'occhio tutte le sue migliaia di connessioni insieme, e reagisce agli eventi: ogni volta che una qualsiasi delle sue connessioni ha qualcosa di pronto da fare, il lavoratore la serve, in un attimo, e poi passa alla successiva che ha qualcosa da fare, e così via. Non aspetta mai, non è mai bloccato: si muove agile tra migliaia di connessioni, servendo di volta in volta quella che ha bisogno adesso.

Voglio darti l'immagine che rende tutto luminoso, perché è perfetta: il cameriere abile che serve molti tavoli. Immagina un solo cameriere bravo, che serve un'intera sala di tavoli. Non sta fermo a un tavolo aspettando: si muove tra tutti. Prende l'ordine a un tavolo, e mentre in cucina lo preparano, non aspetta lì impalato: va a un altro tavolo che ha alzato la mano, poi porta un piatto a un terzo, poi torna al primo che ora è pronto. Serve tutti, un momento ciascuno, sempre in movimento, servendo di volta in volta chi ha bisogno adesso. Un solo cameriere così, che non aspetta mai fermo, serve un'intera sala meglio di cento camerieri fermi a cento tavoli. Questo è il lavoratore di nginx: non aspetta, reagisce, e servendo di volta in volta chi è pronto, ne serve migliaia da solo.

Voglio farti apprezzare perché questa idea risolva il muro delle diecimila connessioni. Nel vecchio modello, ogni connessione costava un lavoratore intero, quasi sempre bloccato ad aspettare: diecimila connessioni, diecimila lavoratori, collasso. In nginx, pochi lavoratori bastano a servirne migliaia, perché nessuno spreca tempo fermo: mentre una connessione aspetta, il lavoratore serve le altre. Il costo per connessione crolla. Ecco come nginx regge decine di migliaia di connessioni con pochissime risorse, dove il vecchio modello sommergeva la macchina. Ha eliminato lo spreco dell'attesa.

Voglio farti apprezzare la bellezza profonda di questa idea, perché va oltre nginx. L'idea di nginx è fare molto di più con molto meno, semplicemente non aspettando mai fermi. È un cambio di prospettiva potentissimo: il collo di bottiglia non era la potenza, ma lo spreco di risorse ferme ad aspettare; e risolverlo non ha richiesto macchine più potenti, ma un modo più intelligente di lavorare, che non spreca l'attesa. È una lezione generale: spesso, per superare un muro di scala, non serve più forza bruta, ma ripensare l'architettura, il modo stesso di organizzare il lavoro, per eliminare lo spreco nascosto. nginx ha rotto il muro non con più potenza, ma con più intelligenza nell'organizzazione. Ed è per questo che è così efficiente.

Voglio chiudere collegando questa idea al carattere di nginx. Da questa architettura a eventi discende tutto ciò per cui è amato: la leggerezza, perché non spreca risorse in lavoratori fermi; la capacità di reggere traffico enorme, perché pochi lavoratori bastano per moltissimi; l'efficienza, perché fa tanto con poco. L'architettura a eventi non è un dettaglio: è il segreto da cui nasce tutto il carattere di nginx. La ritroveremo sotto ogni sua virtù. nginx è, prima di tutto, il web server che ha imparato a non aspettare mai fermo, e da lì viene la sua forza.

Per oggi ci fermiamo qui. nginx rompe il muro delle diecimila connessioni con l'architettura a eventi: pochissimi lavoratori, ognuno dei quali gestisce migliaia di connessioni insieme, senza mai restare fermo ad aspettare. Come un cameriere abile che serve un'intera sala muovendosi tra i tavoli, servendo di volta in volta chi ha bisogno adesso, il lavoratore di nginx reagisce agli eventi e non è mai bloccato. Così elimina lo spreco dell'attesa, e regge una scala enorme con pochissime risorse. È l'idea di fare molto di più con molto meno, ripensando l'organizzazione invece di aggiungere potenza. E da qui nasce tutto il carattere di nginx. Nella prossima puntata vediamo il suo ruolo moderno: la porta d'ingresso, il reverse proxy. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.