Original, source-backed articles about running small systems, static sites, HTTP, DNS, TLS, and operations.
Posts are original articles written for this site. Each one is script-free, source-backed, and tied to the same operational reality the rest of the site records: how a small, static, publicly served system is built, secured, and kept honest.
A surrogate key keeps identity apart from meaning
A surrogate primary key separates row identity from a business value that can change. A customer’s email can be corrected while orders continue referencing the same customer identifier. This is useful when the business name is mutable or wide, but stability comes from schema and application policy. A generated number is not automatically immutable, secret, globally unique, or an authorization decision.
...
Socket activation starts a service only when needed
The port is always ready while the process only starts when someone knocks, a neat trick for rare but heavy services. Every idle daemon costs something: resident memory, periodic wakeups, patch surface, log noise. Multiplied across dozens of seldom-used services on one host, the tax funds nothing. Socket activation inverts the deal — the kernel holds the listening socket, systemd owns it before any daemon exists, and the service process is born only when the first connection arrives carrying real work.
...
A slower query needs both a plan and a wait check
A formerly fast query can become slow with the same data, statistics, and access plan. Another transaction may hold a lock, the storage cache may be colder, or the application may wait before PostgreSQL even receives the statement. Rechecking the plan is useful, but it belongs inside a broader comparison of where the elapsed time went. Begin by distinguishing time spent doing work from time spent waiting to do it.
...
gzip, HTTP/2, and Brotli need separate verification
HTTP/2 changes HTTP transport framing and multiplexing; gzip and Brotli encode representation data. Enabling HTTP/2 does not automatically compress response bodies, and enabling gzip does not prove that a client negotiated HTTP/2. HTTP/2 header compression is another mechanism again. A reliable check records the negotiated protocol, response Content-Encoding, transferred body size, and the bytes obtained after decoding.
...
Postgres uses two cache layers
For ordinary buffered relation I/O, PostgreSQL’s shared buffers sit above the operating system’s file cache. A shared-buffer hit avoids another read through that lower layer; a shared-buffer miss can still be served from memory by the operating system. The same file data can occupy both caches, so this is not a promise that PostgreSQL and the kernel share one physical copy.
...
Recording rules store scheduled query results
A recording rule runs a PromQL expression at scheduled evaluation times and stores the result as a new metric. Repeated dashboard queries can then read that metric instead of recomputing the expression. Calling this a cache can obscure an important difference: the recorded series has its own sample history, cadence, and labels. It is not a transparent cache of every possible query request.
...
Redis geo handles locations by distance
Redis geospatial commands index named locations and answer nearby-point queries without returning every coordinate to the application. They are useful when spherical distance is an acceptable model. They do not provide road routes, altitude-aware separation, arbitrary polygon analysis, or a guarantee that every returned location is still current.
...
Hash indexes recheck collisions and maintain changed keys
PostgreSQL hash indexes narrow an equality search using a hash code, then verify the original value in the table. A hash match is a candidate, not proof of equality. Two different values can have the same code, and different codes can also map to the same bucket. Neither collisions nor shared buckets imply incorrect query results when the normal recheck is performed.
...
