Before a public change
Capture the outside contract
- Save the current DNS, TLS, redirect, status, and body marker.
- Write the expected result and the last known-good version.
- Repeat the same check from outside after the change.
Software · systems · practice
Notes from maintaining small systems.
A working record of measurements, infrastructure choices, and the reasoning that is easiest to lose once something starts working.
Read the latest noteNotebook log
Recent notes
Short records of what worked, what did not, and which details are likely to matter again.
-
→
An alert needs a next action
A response contract for user-visible symptoms, deliberate interruptions, clear ownership, safe first moves, and tested notification delivery.
-
→
A rollback needs compatible data
A staged field migration with compatible reads and writes, concurrency-safe backfills, mixed-version tests, and an explicit rollback boundary.
-
→
A queue needs an age limit
A contract for useful queued work: waiting-time measurements, expiry decisions, revision checks, recovery budgets, and deliberate replay.
-
→
A green check needs a scope
An evidence record for naming what passed, defining when it expires, and repeating only the checks a change invalidates.
-
→
A timeout leaves the outcome unknown
How to recover from a lost response: inspect operation state, preserve intent, bound retries, and test for duplicate work.
-
→
A backup is a recovery claim
A recovery contract for consistent backups, independent access, clean restores, service checks, timed drills, and deliberate retirement.
-
→
A cache key is part of the release
A release contract for versioned assets, deliberate cache rules, atomic publishing, multi-origin checks, and complete rollback.
-
→
Closed by default, open on purpose
A practical lifecycle for short-lived access: explicit leases, verified activity, fail-closed expiry, and outside checks.
-
→
A preflight for a small public service
A repeatable check for DNS, TLS, external behavior, monitoring, and recovery before a service becomes public.
-
→
Keeping small systems legible
A one-page service record and a five-minute check for keeping a small system understandable.
-
→
Measure before tuning
A measurement record for preserving conditions, raw observations, variation, and the decision behind a result.
-
→
Reducing moving parts
An operational inventory and retirement checklist for removing responsibilities without leaving stale obligations.
Quick reference
Three checks worth repeating
Short enough to use during ordinary work, specific enough to catch the detail that usually gets skipped.
Before tuning
Make the result comparable
- Name the decision the measurement is meant to change.
- Fix the input, environment, warm-up, run count, and metric.
- Keep raw values beside the conclusion and its limits.
Before removing a component
Retire its obligations too
- Map consumers and stop new writes before deletion.
- Preserve required state and keep a short reversal window.
- Revoke identity, routes, checks, alerts, and stale documents.
Publishing method
A notebook, not a feed.
Entries are added when a measurement, failure, or design decision is worth preserving. The site has no analytics, comments, or newsletter—just pages that can be read without a client-side application.
How the notebook is kept- Focus
- Software, systems, networking
- Cadence
- Irregular, by design
- Delivery
- Static files, no tracking