Cosa fa davvero il DNS a ogni richiesta Ogni richiesta verso example.com inizia con una ricerca che non ha niente a che fare con la tua applicazione: qualcosa deve trasformare quel nome in un indirizzo IP prima che un solo pacchetto TCP lasci la macchina. Quella traduzione è il DNS, il Domain Name System, e gira a ogni richiesta, che il client sia un browser, curl, o un servizio backend che ne contatta un altro tramite hostname. ...

Cosa protegge davvero TLS su una connessione HTTPS Carica una pagina in http:// puro su una rete che non controlli, un aeroporto o il router di un bar, e tutto quello che invii viaggia come testo leggibile. Il percorso dell’URL, i cookie, i campi del form, la password in un POST di login: chiunque su quella rete con uno sniffer di pacchetti li legge mentre passano. TLS, Transport Layer Security, è il protocollo che blocca questo scenario. Si inserisce tra TCP e il protocollo applicativo, quindi quando HTTP inizia a parlare la connessione è già cifrata e legata a un’identità server verificata. HTTPS è semplicemente HTTP eseguito su quella connessione invece che su una in chiaro. ...

Ogni chiamata a un’API LLM ospitata manda il tuo prompt sul server di qualcun altro e ti fattura per token. Se perdi la connessione di rete, smette di rispondere. Ollama toglie di mezzo entrambi i problemi: scarica un modello open-weight sulla tua macchina e lo serve tramite un’API REST su localhost:11434. Un solo binario fa da gestore dei modelli, client di chat e server. Cosa fa davvero Ollama Ollama avvolge llama.cpp e motori di inferenza simili, così non devi mai toccare un flag del compilatore o un percorso di libreria CUDA. ollama pull llama3.2 scarica un file di modello quantizzato (formato GGUF) dal registro di Ollama invece che da Hugging Face, anche se può importare file GGUF anche da lì. Quando esegui il modello, quei pesi passano a un server in background: li carica in RAM (o in VRAM, se trova una GPU compatibile), li tiene residenti per qualche minuto dopo l’ultima richiesta così la successiva è veloce, e li scarica non appena smetti di fare domande. ...

Un endpoint di checkout che ridimensiona l’immagine di un prodotto, invia un’email di conferma e aggiorna un motore di raccomandazione prima di rispondere con 200 OK è veloce quanto il suo passaggio più lento. Se anche uno solo va in timeout, l’intera richiesta fallisce. Una coda di messaggi permette all’endpoint di passare quel lavoro come messaggi e rispondere subito, mentre worker separati lo prendono in carico con i propri tempi. ...

Ogni risorsa cloud che hai mai creato cliccando in una console web (una VM, un load balancer, un record DNS) si può descrivere anche in un file di testo e creare con un solo comando. Il file vive nel repository git, passa da una pull request, e riproduce lo stesso setup su un secondo account senza che nessuno debba ricordare quali nove impostazioni ha cambiato a mano. È questo che fa Terraform. ...

Cosa fa davvero una CDN a una richiesta Un utente a Tokyo che carica una pagina ospitata su un server in Virginia paga quella distanza due volte: una per far arrivare la richiesta, una per far tornare la risposta. La fibra ottica viaggia a una frazione fissa della velocità della luce, e quel solo tragitto costa già 150-200 ms di andata e ritorno prima che l’origine abbia fatto qualsiasi lavoro. Aggiungi una query al database e un salto di rete lento, e una pagina che sembra istantanea per chi sta vicino al server diventa lenta dall’altra parte del pianeta. ...

Una query che impiega 200ms sul tuo database impiega 200ms anche alla milionesima esecuzione, e ogni esecuzione compete per le stesse connessioni, lo stesso I/O su disco e la stessa CPU. Redis tiene la risposta in memoria, su un server che non fa altro, così la milionesima lettura costa un round trip di rete invece di un piano di query. Cosa fa davvero Redis come cache Redis è un key-value store in memoria. I valori vivono in RAM, quindi letture e scritture si misurano in tempi sotto il millisecondo invece delle decine o centinaia di millisecondi che costa una query relazionale una volta che entrano in gioco join, indici sotto pressione o un connection pool occupato. Si affianca al tuo database, non lo sostituisce: la tua applicazione interroga prima Redis e va al database solo quando Redis non ha la risposta. ...

Cosa c’è tra il browser e la tua app Punta il browser su example.com e la richiesta non tocca mai il processo che esegue il tuo codice. Incontra prima qualcos’altro: un server che legge la richiesta, decide quale backend deve rispondere, la inoltra lì e rimanda indietro la risposta come se l’avesse prodotta lui stesso. Quel server è un reverse proxy. Nginx, Caddy, Traefik e HAProxy fanno tutti questo lavoro, così come il load balancer davanti a un cluster Kubernetes. La disposizione non cambia mai: i client parlano con il proxy e con nient’altro. I server reali restano dietro, in qualunque numero e ovunque girino. ...

Fai il pull dell’ultimo main e Git si blocca con CONFLICT (content): Merge conflict in checkout.js. Risolvi il conflitto e nel log compare un commit chiamato Merge branch 'main' into feature/checkout, appoggiato sopra i tre commit che avevi effettivamente scritto tu. Quattro commit, una sola modifica reale. Un collega che legge quella storia il mese prossimo non riesce più a distinguerli. git merge e git rebase rispondono alla stessa domanda: come allineo il mio branch alle modifiche fatte altrove. Lasciano tracce molto diverse, e scegliere quello sbagliato su un branch condiviso causa danni reali. ...