Operating Dependencies
The day-to-day of running databases, queues, caches and scheduled jobs: connection budgets, dead letters, hot keys, and why production time is always UTC.
The standing duties around the one component you cannot restart your way out of: connections, locks, bloat, replication, and change discipline.
A database accepts a finite number of connections. Every instance, worker, job and console session spends from the same pool — so the pool sizes have to add up.
Depth, oldest message age, consumer throughput, failure rate and dead letters — plus the clock-driven cousin, where duplicate and missed runs live.
A DLQ needs an alert, an inspection path, a replay strategy and an owner. Without those four it is a place failures go to be forgotten.
Hit rate, memory, evictions, hot keys and latency — plus the planning question that decides your real architecture: can the system survive losing the cache?
Machine timelines, logs, storage and schedules in UTC; local time only at the edges where a human reads it. The conversion belongs in one place.
The hour that happens twice, the hour that never happens, the billing cutoff in the wrong zone, and the incident timeline nobody can reconcile.
Machines need reasonably synchronised clocks for logs, certificates, tokens and scheduling — reasonably, because perfect synchronisation is not available.