Short notes on building things that remain understandable.
A useful system is one that can be understood after its author has forgotten the details. Small components, explicit boundaries, and a short record of decisions are often more valuable than another layer of abstraction.
Before changing a working setup, write down what success looks like and how to return to the previous state. The same habit makes both experiments and routine maintenance less surprising.
Moving data is not instantaneous. A fast connection can carry a large amount of information, yet still take time to receive the first response. Bandwidth and latency describe different parts of that experience.
Measure from the place where a system will actually be used. A benchmark near the server tells only part of the story.
Backups are most useful when the restoration process is familiar. Keep copies separate from the running service, document the important paths, and test a small recovery before an urgent one becomes necessary.