Ce que le DNS fait vraiment à chaque requête Chaque requête vers example.com commence par une recherche qui n’a rien à voir avec votre application : il faut d’abord transformer ce nom en adresse IP avant qu’un seul paquet TCP ne quitte la machine. Cette traduction, c’est le DNS, le Domain Name System, et elle intervient à chaque requête, que le client soit un navigateur, curl, ou un service backend qui en appelle un autre par son hostname. ...

Ce que TLS protège vraiment sur une connexion HTTPS Chargez une page en http:// en clair sur un réseau que vous ne contrôlez pas, un aéroport ou le routeur d’un café, et tout ce que vous envoyez circule en texte lisible. Le chemin de l’URL, les cookies, les champs du formulaire, le mot de passe dans un POST de connexion : n’importe qui sur ce réseau avec un sniffer de paquets les lit au passage. TLS, Transport Layer Security, est le protocole qui bloque cela. Il se place entre TCP et le protocole applicatif, si bien que quand HTTP commence à parler, la connexion est déjà chiffrée et rattachée à une identité serveur vérifiée. HTTPS, c’est HTTP exécuté sur cette connexion au lieu d’une connexion en clair. ...

Chaque appel à une API de LLM hébergée envoie votre prompt vers le serveur de quelqu’un d’autre et vous facture par token. Coupez la connexion, et elle arrête de répondre. Ollama supprime ces deux problèmes : il récupère un modèle à poids ouverts sur votre machine et le sert via une API REST sur localhost:11434. Un seul binaire fait office de gestionnaire de modèles, de client de chat et de serveur. ...

Un endpoint de checkout qui redimensionne l’image d’un produit, envoie un email de confirmation et met à jour un moteur de recommandation avant de répondre 200 OK n’est jamais plus rapide que son étape la plus lente. Si l’une d’elles dépasse le délai, toute la requête échoue. Une file de messages permet à l’endpoint de confier ce travail sous forme de messages et de répondre immédiatement, pendant que des workers séparés les traitent à leur propre rythme. ...

Chaque ressource cloud que vous avez déjà créée en cliquant dans une console web (une VM, un load balancer, un enregistrement DNS) peut aussi être décrite dans un fichier texte et créée en une seule commande. Le fichier vit dans git, passe par une pull request, et reproduit le même setup sur un second compte sans que personne ait à se souvenir des neuf réglages changés à la main. C’est ce que fait Terraform. ...

Ce qu’un CDN fait réellement à une requête Un utilisateur à Tokyo qui charge une page hébergée sur un serveur en Virginie paie cette distance deux fois : une fois pour que la requête arrive, une fois pour que la réponse revienne. La fibre optique transporte les données à une fraction fixe de la vitesse de la lumière, et ce seul trajet coûte déjà 150 à 200 ms d’aller-retour avant même que l’origine n’ait commencé à travailler. Ajoutez une requête en base de données et un ou deux sauts réseau lents, et une page qui semble instantanée juste à côté devient poussive à l’autre bout de la planète. ...

Une requête qui prend 200ms sur votre base de données prend toujours 200ms la millionième fois que quelqu’un l’exécute, et chacune de ces exécutions se dispute les mêmes connexions, le même I/O disque et le même CPU. Redis garde la réponse en mémoire, sur un serveur qui ne fait que ça, si bien que la millionième lecture coûte un aller-retour réseau au lieu d’un plan de requête. Ce que Redis fait réellement comme cache Redis est un magasin clé-valeur en mémoire. Les valeurs vivent en RAM, donc les lectures et écritures prennent moins d’une milliseconde, contre les dizaines ou centaines de millisecondes que coûte une requête relationnelle dès que des jointures, des index sous pression ou un pool de connexions chargé entrent en jeu. Il se place à côté de votre base de données, pas à sa place : votre application interroge d’abord Redis et ne va à la base de données que si Redis n’a pas la réponse. ...

Ce qui se trouve entre le navigateur et votre app Pointez votre navigateur vers example.com et la requête ne touche jamais le processus qui exécute votre code. Elle rencontre d’abord autre chose : un serveur qui lit la requête, décide quel backend doit répondre, la lui transmet, puis renvoie la réponse comme s’il l’avait produite lui-même. Ce serveur, c’est un reverse proxy. Nginx, Caddy, Traefik et HAProxy font tous ce travail, tout comme le load balancer placé devant un cluster Kubernetes. Le schéma ne change jamais : les clients ne parlent qu’au proxy, à rien d’autre. Les serveurs réels restent derrière, en nombre quelconque et où qu’ils tournent. ...

Vous faites un pull du dernier main et Git s’arrête avec CONFLICT (content): Merge conflict in checkout.js. Vous résolvez le conflit, et le log affiche maintenant un commit nommé Merge branch 'main' into feature/checkout, posé au-dessus des trois commits que vous aviez réellement écrits. Quatre commits, un seul changement réel. Un collègue qui lit cet historique le mois prochain ne peut pas savoir lequel est lequel. git merge et git rebase répondent à la même question : comment mettre ma branche à jour par rapport aux changements faits ailleurs. Ils laissent des traces très différentes, et choisir le mauvais sur une branche partagée cause de vrais dégâts. ...