Artículos

La suite de pruebas lleva tres semanas en verde. Hoy npm test falla en una aserción que no tiene nada que ver con lo que acabas de cambiar, y git log v1.4.0..HEAD muestra 340 commits de cuatro personas desde la última release que alguien confirmó que funcionaba. Leer cada diff te cuesta un día entero. Hacer checkout de commits al azar es más rápido, pero sigue sin ser un plan. ...

Qué hace el DNS en cada petición Toda petición a example.com empieza con una búsqueda que no tiene nada que ver con tu aplicación: algo tiene que convertir ese nombre en una dirección IP antes de que un solo paquete TCP salga de la máquina. Esa traducción es el DNS, el Domain Name System, y se ejecuta en cada petición, sea el cliente un navegador, curl o un servicio backend que llama a otro por hostname. ...

Qué protege TLS realmente en una conexión HTTPS Carga una página por http:// sin cifrar en una red que no controlas, un aeropuerto o el router de una cafetería, y todo lo que envías viaja como texto legible. La ruta de la URL, las cookies, los campos del formulario, la contraseña en un POST de login: cualquiera en esa red con un sniffer de paquetes lo lee al vuelo. TLS, Transport Layer Security, es el protocolo que corta eso. Se sitúa entre TCP y el protocolo de aplicación, así que cuando HTTP empieza a hablar, la conexión ya está cifrada y ligada a una identidad de servidor verificada. HTTPS es HTTP corriendo sobre esa conexión en lugar de una en texto plano. ...

Cada llamada a una API de LLM alojada envía tu prompt al servidor de otra persona y te cobra por token. Se cae la red y deja de responder. Ollama elimina los dos problemas: descarga un modelo de pesos abiertos en tu máquina y lo sirve mediante una API REST en localhost:11434. Un solo binario hace de gestor de modelos, cliente de chat y servidor. Qué hace Ollama en realidad Ollama envuelve llama.cpp y motores de inferencia similares, así que nunca tocas un flag del compilador ni una ruta de biblioteca CUDA. ollama pull llama3.2 descarga un archivo de modelo cuantizado (formato GGUF) desde el propio registro de Ollama en lugar de Hugging Face, aunque también puede importar archivos GGUF desde allí. Ejecutar el modelo pasa esos pesos a un servidor en segundo plano, que los carga en RAM (o VRAM, si encuentra una GPU compatible), los mantiene en memoria unos minutos después de tu última petición para que la siguiente sea rápida, y los libera en cuanto dejas de preguntar. ...

Un endpoint de checkout que redimensiona la imagen de un producto, envía un email de confirmación y actualiza un motor de recomendaciones antes de responder con 200 OK es tan rápido como su paso más lento. Si uno solo hace timeout, toda la petición falla. Una cola de mensajes permite que el endpoint entregue ese trabajo como mensajes y responda de inmediato, mientras workers separados lo recogen a su propio ritmo. ...

Cualquier recurso cloud que hayas creado haciendo clic en una consola web (una VM, un load balancer, un registro DNS) también se puede describir en un archivo de texto y crear con un solo comando. El archivo vive en git, pasa por una pull request y reproduce el mismo setup en una segunda cuenta sin que nadie tenga que recordar qué nueve ajustes cambió a mano. Eso es lo que hace Terraform. ...

Qué hace un CDN realmente con una petición Un usuario en Tokio que carga una página alojada en un servidor de Virginia paga esa distancia dos veces: una vez para que la petición llegue, otra para que la respuesta vuelva. La fibra viaja a una fracción fija de la velocidad de la luz, y ese trayecto por sí solo cuesta entre 150 y 200ms de ida y vuelta antes de que el origen haya hecho ningún trabajo. Añade una consulta a la base de datos y algún salto lento de más, y una página que se siente instantánea a la vuelta de la esquina se siente lenta al otro lado del planeta. ...

Una consulta que tarda 200ms contra tu base de datos sigue tardando 200ms la millonésima vez que alguien la ejecuta, y cada una de esas ejecuciones compite por las mismas conexiones, el mismo I/O de disco y la misma CPU. Redis guarda la respuesta en memoria, en un servidor que no hace nada más, así que la lectura número un millón cuesta un round trip de red en lugar de un plan de consulta. ...

Qué hay entre el navegador y tu app Apunta el navegador a example.com y la petición nunca toca el proceso que ejecuta tu código. Primero llega a otra cosa: un servidor que lee la petición, decide qué backend debe responder, la reenvía ahí y devuelve la respuesta como si la hubiera generado él mismo. Ese servidor es un reverse proxy. Nginx, Caddy, Traefik y HAProxy hacen todos este trabajo, igual que el load balancer que se sienta delante de un clúster de Kubernetes. El esquema no cambia nunca: los clientes hablan con el proxy y con nada más. Los servidores reales quedan detrás, sean los que sean y estén donde estén. ...

Haces pull del último main y Git se detiene con CONFLICT (content): Merge conflict in checkout.js. Resuelves el conflicto y el log muestra ahora un commit llamado Merge branch 'main' into feature/checkout, sentado encima de los tres commits que en realidad escribiste tú. Cuatro commits, un solo cambio real. Un compañero que lea ese historial el mes que viene no puede saber cuál es cuál. git merge y git rebase responden a la misma pregunta: cómo pongo mi rama al día con los cambios hechos en otro sitio. Dejan rastros muy distintos, y elegir el equivocado en una rama compartida causa daño real. ...