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.
Backups are untested hope without proof
A completed backup job establishes that the backup process produced an artifact. A restore rehearsal establishes whether that artifact, the available tooling, and the required environment can produce a usable system. These are different claims. Recovery evidence should identify the backup used, the state recovered, the dependencies supplied, and the time needed to make the result useful to the application.
...
Redis keys read well with clear naming
Redis keys are binary-safe names in a flat keyspace, not filesystem paths or schema declarations. Colons are a useful convention for separating ownership, environment, entity, and identifier. A name such as cart:prod:string:42 can explain intent, but Redis does not interpret those labels as a type check or access restriction.
...
A plain read keeps its statement snapshot
In PostgreSQL Read Committed, an ordinary table read uses a snapshot established for that statement. Another transaction can commit while the read is running, yet the table scan continues using its original visibility boundary. The next statement can see the new commit. This explains how one transaction can obtain individually consistent answers that differ between statements, without either statement observing an uncommitted intermediate update.
...
Sequential identifiers reveal allocation patterns
A sequential identifier makes nearby values easy to guess. Seeing order number four thousand gives an observer a useful place to probe, and collecting identifiers over time may reveal allocation activity. It does not establish that four thousand orders exist, that all numbers represent successful purchases, or that the largest identifier committed last. Those conclusions require information that a sequence does not contain.
...
HTTP keep-alive reuses one TCP connection
HTTP persistence lets several request and response exchanges use one connection. That can avoid repeated TCP setup and, for HTTPS, repeated TLS negotiation. The benefit depends on latency, request size, and whether another usable connection already exists. Persistence does not make application work disappear, nor does it promise that a socket will remain open indefinitely.
...
Requests guide placement; limits constrain resource use
Requests guide placement and resource sharing; limits constrain runtime consumption. They are related inputs, not a universal floor-and-ceiling guarantee for application performance. Choose them from workload behavior, contention risk and recovery requirements. Inspect the admitted Pod because defaults and policy can change the resource values submitted in a manifest.
...
A read-through cache loads on a miss by itself
Read-through caching gives callers one reading interface: a hit returns a stored value, while a miss invokes a loader and stores its result. The important boundary is who owns that loader. Moving it behind the cache interface can remove duplicated lookup logic, but does not automatically solve concurrency, writes, authorization, or consistency between independent copies.
...
Foreign keys keep references honest
A foreign key makes a relationship enforceable during ordinary database writes. A task can reference an existing project, and the database can reject an unknown project identifier even when an import or a new application code path forgets to check it. The constraint defines referential integrity; it does not decide whether the selected project is the correct one for the business operation.
...
