Articles

A workflow that runs npm ci on every push downloads the same few hundred packages from the registry each time, even when the lockfile hasn’t changed in a week. On a project with a real dependency tree that’s a minute or two gone before the first test starts, and you pay it again on every push and every pull request. actions/cache keeps those downloads between runs and hands them back when nothing relevant has changed. ...

The test suite has been green for three weeks. Today npm test fails on an assertion that has nothing to do with what you just changed, and git log v1.4.0..HEAD shows 340 commits from four people since the last release anyone is sure worked. Reading every diff costs you a day. Checking out commits at random is faster and still not a plan. git bisect turns that into a binary search. You give it one commit you know is good and one you know is bad; it checks out the commit halfway between them and waits while you test that single commit and report back. Each answer halves the range. 340 commits resolve in at most 9 tests, since 2^9 = 512. ...

What DNS actually does on every request Every request to example.com starts with a lookup that has nothing to do with your application: something has to turn that name into an IP address before a single TCP packet leaves the machine. That translation is DNS, the Domain Name System, and it runs on every request, whether the client is a browser, curl, or a backend service calling another backend by hostname. ...

What TLS actually protects on an HTTPS connection Load a page over plain http:// on a network you don’t control, an airport or a coffee-shop router, and everything you send travels as readable text. The URL path, the cookies, the form fields, the password in a login POST: anyone on that network with a packet sniffer reads it as it goes past. TLS, Transport Layer Security, is the protocol that stops that. It sits between TCP and the application protocol, so by the time HTTP starts talking, the connection is already encrypted and tied to a verified server identity. HTTPS is HTTP run over that connection instead of a plain one. ...

Every call to a hosted LLM API sends your prompt to someone else’s server and bills you per token. Lose the network and it stops answering. Ollama takes both problems out of the loop: it pulls an open-weight model onto your machine and serves it over a REST API on localhost:11434. One binary is the model manager, the chat client, and the server. What Ollama actually does Ollama wraps llama.cpp and similar inference engines so you never touch a compiler flag or a CUDA library path. ollama pull llama3.2 fetches a quantized model file (GGUF format) from Ollama’s own registry rather than from Hugging Face, though it can import GGUF files from there too. Running the model hands those weights to a background server, which loads them into RAM (or VRAM, if it finds a compatible GPU), keeps them resident for a few minutes after your last request so the next one is fast, and unloads them once you stop asking. ...

A checkout endpoint that resizes a product image, sends a confirmation email, and updates a recommendation engine before returning 200 OK is only as fast as its slowest step. If any one of them times out, the whole request fails. A message queue lets the endpoint hand that work off as messages and return immediately, while separate workers pick them up on their own schedule. What a message queue actually does A message queue sits between two parts of a system that don’t need to run at the same moment. A producer publishes a message describing work to be done. The queue holds it. A consumer picks it up, processes it, and acknowledges it. The two never talk to each other directly. ...

Every cloud resource you have ever clicked into existence in a web console (a VM, a load balancer, a DNS record) can also be described in a text file and created by running one command. The file lives in git, gets reviewed in a pull request, and reproduces the same setup on a second account without anyone remembering which nine settings they changed by hand. That is what Terraform does. ...

What a CDN actually does to a request A user in Tokyo loading a page hosted on a server in Virginia pays for that distance twice: once for the request to arrive, once for the response to come back. Fiber runs at a fixed fraction of the speed of light, and that trip alone costs on the order of 150-200ms round-trip before the origin has done any work. Add a database query and a slow hop or two, and a page that feels instant next door feels sluggish on the other side of the planet. ...

A query that takes 200ms against your database still takes 200ms the millionth time someone runs it, and every one of those runs competes for the same connections, disk I/O, and CPU. Redis keeps the answer in memory, on a server that does nothing else, so the millionth read costs a network round trip instead of a query plan. What Redis actually does as a cache Redis is an in-memory key-value store. Values live in RAM, so reads and writes measure in sub-millisecond time instead of the tens or hundreds of milliseconds a relational query costs once you add joins, indexes under pressure, or a busy connection pool. It sits next to your database, not in place of it: your application asks Redis first and goes to the database only when Redis doesn’t have the answer. ...

What sits between a browser and your app Point a browser at example.com and the request never touches the process running your code. It hits something else first: a server that reads the request, decides which backend should answer, forwards it there, and sends the response back as if it had produced that response itself. That server is a reverse proxy. Nginx, Caddy, Traefik and HAProxy all do this job, and so does the load balancer sitting in front of a Kubernetes cluster. The arrangement never changes: clients talk to the proxy and to nothing else. The real servers stay behind it, however many there are and wherever they run. ...