Just Ask
Ask me anything about software architecture, careers, PHP, Go and the craft of building software; I answer here, in the open, for everyone.
Whatever's on your mind, don't hold back. Questions reach me directly; I answer the good ones and publish them on this page. Your email is never published.
In Kubernetes, probes own readiness/liveness; the kubelet ignores the Dockerfile HEALTHCHECK by design. But keep a HEALTHCHECK for Compose/plain Docker, and point both at the same endpoint.
Never silently remove an endpoint paying partners use. Run an announced, dated, measured sunset: communicate, signal in the response headers, watch usage drop to zero, then remove.
If the same query gets a different plan, the planner's cost estimate differs. On a heavily-written sessions table the cause is almost always stale statistics + table bloat, not a missing index.
A steadily climbing goroutine count = goroutines blocked forever on a channel/lock/IO with no cancellation path. Take a pprof dump first, then make the spawn site honor context.
Run it fully strict (throw) in local and CI; keep it on in production but wire it to a handler that logs instead of throwing. Flipping raw throwing on cold in prod turns latent bugs into outages.
For a module you're actively working in it's worth it: you gain type safety, behavior living with the value, and DB compatibility via the same integers; the cost is boundary casting and lost flexibility.
Don't make a human watch a dashboard — wire the metrics into the deploy. The pattern: progressive delivery + automated analysis. After deploy, hold at a canary weight for a bake period querying 5xx/latency against a threshold; on breach, auto-roll back to the last good version and alert a human.
Yes, it's a valid pattern — Cloudflare Zero Trust recommends something similar. But you have to accept a single ingress path, never bind the app to 0.0.0.0, queue long-running work for Cloudflare's limits, and set trusted proxies.
Make Canary your default for routine releases (smallest blast radius), and keep Blue-Green for big cutovers where you want an instant flip/rollback. The real pivot is the database: both demand backward-compatible (expand/contract) schema changes.
If the key sits in `.env` next to the data, an attacker who reaches the server gets both the data and the key; the encryption buys almost nothing. KMS/Vault separate the key from the data and never expose the raw key to the app (envelope encryption). Prefer tokenization for national IDs/card data; rotate + audit.