DEV Community: Parsa Aftabi

Read the migration before production does: miglens, a local-AI migration-risk explainer in Go

Parsa Aftabi — Tue, 27 Oct 2026 07:14:59 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine

What I Built

miglens reads a SQL migration and tells you what is risky about it before you run it: first with a deterministic rule scan, then in plain English from a local open-weight model.

miglens migrations/0042_orders_cleanup.sql
cat migration.sql | miglens -model llama3.2:1b

The dangerous line in a migration is rarely a syntax error. It is the DROP COLUMN that deletes data a still-running service needs, the ADD COLUMN ... NOT NULL that fails on a table with two million rows, the CREATE INDEX that quietly blocks writes for twenty minutes. Linters check style. miglens checks blast radius.

Fitting this week's theme, a migration is where a codebase keeps its ghosts: dropped columns that old code still reaches for, dead tables nobody owns, constraints added in a hurry that haunt every deploy after. miglens finds those ghosts while they are still just lines in a file, before they start haunting production.

Two layers, in order:

Rule scan (always runs, fully offline). Fifteen rules with severity, line number, a plain explanation, and a safer way to do the same thing. Dropping a table or column is CRITICAL, whole-table writes without a WHERE and NOT NULL without a DEFAULT are HIGH, a non-concurrent index build is MEDIUM, and so on.
AI summary (optional, local). The findings plus the migration go to a model running in Ollama on my own machine, which answers in a fixed shape: what could break, who it affects, a safer alternative, and a rollout order.

If Ollama is not running, miglens prints the full scan, a short note on how to enable the summary, and exits 0. The scan is the source of truth. The model only explains it.

Demo

examples/risky.sql packs five classic mistakes into one small migration. Real output from a local run with llama3.2:1b:

$ ./miglens -model llama3.2:1b examples/risky.sql
== examples/risky.sql ==
5 findings: 1 critical, 3 high, 1 medium

line 4  CRITICAL  drop-column
  > ALTER TABLE orders DROP COLUMN legacy_code;
  Dropping a column permanently deletes that data, and any running code that still reads or writes the column starts failing immediately.
  Safer: Ship code that ignores the column first (expand/contract), then drop the column in a later migration.

line 7  HIGH  add-column-not-null
  > ADD COLUMN discount_code text NOT NULL;
  Adding a NOT NULL column without a DEFAULT fails on tables that already have rows, and on newer Postgres versions it still takes a lock while the default is applied.
  Safer: Add the column nullable (or with a DEFAULT), backfill existing rows, then add the NOT NULL constraint.

line 9  MEDIUM  create-index-not-concurrent
  > CREATE INDEX idx_orders_customer_id ON orders (customer_id);
  CREATE INDEX without CONCURRENTLY blocks writes to the table until the index is built, which on a large table means downtime.
  Safer: Use CREATE INDEX CONCURRENTLY (outside a transaction) so writes keep flowing during the build.

And the local model on the same findings:

--- AI summary (local model) ---
The worst realistic outcome could be that the database is permanently
locked and unusable for a certain period, causing disruptions to users,
services, and jobs that rely on the orders table.

Honest note, same as last time: the 1B model is loose. It gets the shape of the answer but not the precision, and the summary gets sharper with llama3.2:3b. The tool does not care which one you run. That is the point of building on a local, swappable model. The deterministic scan underneath is exact either way: right lines, right severities, every time.

Code

miglens is one Go module with zero dependencies, standard library only:

cmd/miglens: flags and env config (-model, -host, -no-ai, OLLAMA_HOST, OLLAMA_MODEL), file or stdin input
internal/rules: the pattern engine: walks the SQL statement by statement, comments stripped with line numbers preserved, one finding per rule per statement
internal/report: renders the scan: counts by severity, then each finding with its line, explanation, and safer alternative
internal/prompt: builds the fixed-shape summary request, worded so the model reports impact instead of inventing root causes
internal/ollama: a thin client for Ollama's /api/generate; unreachable server or missing model is a note, never a failed run

53 unit tests cover the rule engine (including exact line and severity assertions on the shipped risky example, and zero findings on the safe one), the report renderer, the prompt builder, and the client against a stub Ollama server. go build ./... and go test ./... are green.

How I Built It

The layering came first, before any code. An AI summary of a migration is only worth reading if something exact sits underneath it, because a small local model will happily sound confident about the wrong line. So the deterministic scan owns the facts, and the model owns the explanation. If the model is down, vague, or not pulled yet, you lose adjectives, not correctness.

The unglamorous problems:

SQL is not line-shaped. Statements span lines, comments sit inside them, and a finding that points at the wrong line is worse than no finding. The engine strips comments while preserving line numbers, then reports the exact line where a pattern matched inside a multi-line statement.
Rules interact. CREATE INDEX CONCURRENTLY cannot run inside a transaction, so flagging "no transaction" on a file that uses CONCURRENTLY would be a false alarm. The missing-transaction rule stays quiet when CONCURRENTLY is present.
Failure should teach. A missing model or a stopped Ollama prints exactly how to fix it (ollama serve, ollama pull llama3.2:3b) and the run still ends with the full scan in hand.

Why Does Open Innovation Matter?

A production schema is a map of the business: table names, column names, the shape of the data, which parts are being changed and why. Sending a migration to a hosted AI API sends that map to someone else's computer, under someone else's retention policy, usually minutes before a deploy, when nobody is stopping to think about data policy.

A local open-weight model removes the question entirely. The migration stays on the machine that wrote it. It costs nothing per call, works with the network cable unplugged, and the model can be swapped the day a better open one drops. And because the deterministic layer needs no model at all, the tool still earns its place in a CI pipeline on a box with no GPU and no Ollama.

The Spirit of It

Reviewing a migration by hand means holding the whole table in your head: how big it is, what locks each statement takes, which deploy order makes it safe. miglens does that first pass in seconds and hands me five findings with line numbers instead of forty lines of raw SQL. It does not make the migration safe. It makes sure I am not the last thing standing between a DROP COLUMN and production.

My logs never leave the box: logwhisper, a local-AI log explainer in Go

Parsa Aftabi — Sun, 25 Oct 2026 21:57:25 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

logwhisper is a small Go CLI that reads production log lines and explains them in plain English: what happened, the likely cause, and the next thing to check.

logwhisper examples/production.log
cat app.log | logwhisper -model llama3.2:3b

The AI part runs entirely on my own machine through Ollama and an open-weight model (Llama 3.2). No API key, no cloud call, no log line ever leaving the box.

Who gets to be a little lazier because of it? The on-call version of me. The tool was born from a familiar 2 a.m. scene: an incident, a wall of log lines, and the slow work of reading them one by one until a pattern shows up. logwhisper does the first pass — the reading — so the human can start at the diagnosis.

Demo

A sample incident log ships in the repo (examples/production.log): a Go service whose Postgres runs out of connection slots at 02:15 and starts failing requests. Here is logwhisper on it, running the small llama3.2:1b model locally:

$ ./logwhisper -model llama3.2:1b examples/production.log

5. "Slow query" - A query to retrieve orders was slow, taking 1,823 milliseconds to complete.
6. "Query failed" - A query to insert order items failed due to a connection error.
7. "Request failed" - A POST request to create order items failed due to a connection error.
10. "Connection pool waiting" - The connection pool is waiting for 37 requests to be fulfilled.
11. "Query failed" - A query to retrieve the balance of a specific user failed due to a password authentication error.
12. "Read replica disabled" - The read replica database is disabled, and the server is falling back to the primary database.
16. "Postgres connections still high" - There are still high levels of connections to Postgres.

Honest note: the 1B model mostly narrates line by line. It reads the log back to you in plain words, which is already useful at 2 a.m., but the real cause-and-effect synthesis gets noticeably better with llama3.2:3b. The tool doesn't care which one you run — that's the point of building on a local, swappable model.

Code

logwhisper is one Go module with zero dependencies — standard library only:

cmd/logwhisper — flags and env config (-model, -host, OLLAMA_HOST, OLLAMA_MODEL), stdin or file input
internal/chunk — splits long logs into pieces a small model's context window can actually hold (40 lines / 6000 bytes by default, never splits a line in half)
internal/prompt — a fixed What happened / Likely cause / Next check template, worded to stop a small model from inventing a root cause it can't see
internal/ollama — a thin client for Ollama's /api/generate, with an honest error when Ollama isn't running that tells you exactly how to start it

Unit tests cover the chunking, the prompt builder, and the client (including an unreachable-server case and a stub Ollama server). go build ./... and go test ./... are green.

How I Built It

The design constraint came first: whatever I built, the model had to be open and local. Ollama made that part boring in the best way — pull a model, get an HTTP API on localhost:11434, done.

The interesting problems were the unglamorous ones:

Context windows are small. A real incident log doesn't fit in a 1B model's context. So logwhisper chunks by lines and bytes and explains piece by piece, labeling each part.
Small models bluff. Ask a small model "what's the root cause?" and it will happily invent one. The prompt template separates observation ("what happened") from hypothesis ("likely cause") and tells the model to say when the log doesn't contain the answer.
Failure should teach. If Ollama is down, the tool exits with the exact commands to fix it (ollama serve, ollama pull llama3.2:3b) instead of a naked dial error.

Why Does Open Innovation Matter?

Production logs are some of the most sensitive text a company produces: user IDs, IPs, query parameters, the exact shape of every failure. Pasting them into a hosted AI API means sending that text to someone else's computer, under someone else's retention policy — at 2 a.m., under incident pressure, when nobody is thinking about data policy.

A local open-weight model removes the question entirely. The log stays on the box that produced it. It also costs nothing per call, works with the network cable unplugged, and the model can be swapped the day a better open one drops — I ran the same binary against the 1B and 3B Llama 3.2 builds without changing a line of code.

Slow and steady is also how incidents actually get solved: read carefully, form a hypothesis, check one thing. logwhisper just takes the first, slowest step off my plate.

The Lazy Payoff

Reading a 200-line incident log cold takes me roughly ten minutes before I even start forming a hypothesis. logwhisper's pass takes seconds, and I start from a plain-English summary instead of raw text. It doesn't fix the incident — it gets me to the fixing part faster, with the log never leaving the machine.

The http.Server Setup I Use in Every Go Project — Now Open Source

Parsa Aftabi — Tue, 20 Oct 2026 04:03:05 +0000

Every Go API I ship starts life with the same block of code.

Not the handlers, not the routing. The server setup. Timeouts, signal handling, the shutdown dance. I'd copy it from the last project, change a number or two, and move on. After the fifth or sixth time I stopped pretending it was project code. It's infrastructure, so I extracted it.

It's called graceful. Zero dependencies, about 200 lines of code you can read in one sitting. Here's what it does and why.

The stdlib defaults are a footgun

http.Server ships with every timeout set to zero. Zero doesn't mean "sensible default". It means no timeout at all.

A client that connects and sends its headers one byte at a time will hold that connection open forever. That's slowloris, and it's not exotic — it's the default behavior of the server most Go APIs run on. Same story on the write side: a handler writing to a dead connection can block indefinitely, because nothing bounds it.

Every production server needs five things, and the standard library leaves all five at zero values:

Real timeouts on reads and writes
Signal handling for SIGINT/SIGTERM
Draining in-flight requests instead of dropping them
Cleanup that runs in a sane order (DB pools, telemetry flush)
A deadline on shutdown itself, so it can't hang forever

None of this is hard. It's just boilerplate you have to remember, every time, in exactly the right order.

The setup

mux := http.NewServeMux()
mux.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
    w.WriteHeader(http.StatusOK)
})

srv := graceful.New(mux,
    graceful.WithAddr(":8080"),
    graceful.WithOnShutdown(func(ctx context.Context) error {
        return db.Close()
    }),
)
if err := srv.Run(context.Background()); err != nil {
    log.Fatal(err)
}

That's the whole thing. Run blocks until the context is cancelled or a signal arrives, drains in-flight requests, runs your hooks, and returns. ErrServerClosed never surfaces as an error, because it isn't one.

The defaults I landed on after running this shape in production:

Setting	Default	Why
ReadHeaderTimeout	5s	Headers must arrive fast. This is the slowloris guard.
ReadTimeout	10s	Bounds the full request read, body included.
WriteTimeout	30s	Bounds the full response write, handler time included.
IdleTimeout	120s	Keep-alive connections don't linger forever.
ShutdownTimeout	20s	Requests and hooks finish inside this, or not at all.

Every one of them is overridable with a With... option. WriteTimeout is the one people get wrong most often — if you serve large exports or SSE, raise it first and ask questions later.

Shutdown hooks, in order

When Kubernetes sends SIGTERM, the order matters. Stop accepting new connections first. Let in-flight requests finish. Then close things, in the order you registered them.

Hooks in graceful run sequentially after the listener drains. Each one gets the shutdown context, which is cancelled at the ShutdownTimeout deadline. If a hook fails, it's logged and the rest still run — one misbehaving cleanup shouldn't block closing the database pool.

What it deliberately doesn't do

No router. No middleware chain. No config files, no framework, no opinions about your handlers. It's a server lifecycle wrapper and nothing else, which is exactly why it's 200 lines and has zero dependencies. If you need more than this, you don't need a bigger version of graceful — you need a framework, and that's a different decision.

The full *http.Server is exposed via HTTPServer() if you need ConnState hooks or HTTP/2 tuning, and WithTLS takes a cert and key (passing only one is a config error, caught at startup, not at 3am).

Try it

go get github.com/parsaaftabi/graceful

Repo: https://github.com/parsaaftabi/graceful — issues and PRs welcome. If your timeout defaults differ from mine, I'm genuinely curious what you run and why. That's the part of this setup that never stops being project-specific.

PostgreSQL EXPLAIN ANALYZE: What I Actually Look At in Query Plans

Parsa Aftabi — Fri, 16 Oct 2026 23:18:51 +0000

PostgreSQL EXPLAIN ANALYZE: What I Actually Look At in Query Plans

Every slow query I have ever chased started the same way: someone guessing. "Probably needs an index." "The join is too big." "Postgres is slow today." Guessing is how you add three indexes, change nothing, and learn nothing.

EXPLAIN ANALYZE ends the guessing. It runs the query and tells you exactly where the time went. Here is how I read one, in the order I actually read it, and what each part is telling me.

One warning first, because it bites people: ANALYZE executes the statement. On a SELECT that is fine. On an INSERT, UPDATE, or DELETE, wrap it in a transaction and roll back:

BEGIN;
EXPLAIN (ANALYZE, BUFFERS) UPDATE orders SET status = 'x' WHERE id = 1;
ROLLBACK;

Forget the rollback once and you will remember it forever.

1. Always add BUFFERS

Plain EXPLAIN ANALYZE tells you time. EXPLAIN (ANALYZE, BUFFERS) tells you time plus where the data came from:

Buffers: shared hit=42 read=8190

hit means the page was already in Postgres's cache. read means it went to disk. A query with 8000 reads and 42 hits is not slow because the plan is bad. It is slow because nothing it needs is cached. That is a completely different problem from a bad join, and it changes everything you do next. Without BUFFERS you cannot tell them apart, so I never run a plan without it.

If you want the disk time broken out too, track_io_timing needs to be on, but the hit/read split alone answers most questions.

2. Read bottom-up, and multiply by loops

A plan is a tree. Postgres executes the leaves first and the results flow upward, so the most expensive thing is usually near the bottom, not the top. Start at the bottom.

Two mechanics people get wrong:

Time is cumulative. The actual time on a node includes all its children. To get what a node itself cost, subtract the children. The node with the biggest exclusive time is where your query is actually dying.

Loops multiply. This line is the classic killer:

->  Index Scan using orders_user_id_idx on orders  (actual time=0.012..0.031 rows=3 loops=184200)

That index scan looks cheap: 0.03 milliseconds. But it ran 184,200 times, once per outer row. That is 184,200 tiny index probes, which is 184,200 rounds of random I/O. The per-loop number lies to you. The total is what you pay.

Whenever I see a high loop count on an inner node, I already know the shape of the fix before reading further: the outer side is too big for a nested loop, or the inner side needs to be cheaper.

3. Estimated rows vs actual rows: the gap is the signal

Every node shows two row counts: what the planner guessed (rows=) and what actually came back (actual rows=). The single most informative number in the whole plan is the ratio between them.

Seq Scan on events  (actual rows=4 loops=1)
   Filter: (created_at > '2026-10-01')
   Rows Removed by Filter: 987331

The planner thought this filter would match a lot of rows. It matched 4. When the estimate is off by orders of magnitude, the planner picks the wrong strategy for the wrong data shape, and everything downstream is built on that lie.

Do not tune the query first. Fix the estimate. Nine times out of ten it is stale statistics: run ANALYZE on the table and look again. If the stats are fresh and the gap persists, the query is shaped in a way statistics cannot model: a function applied to the column (WHERE lower(email) = ...), a LIKE '%...%' with a leading wildcard, or a predicate the planner has no stats for. Then you change the query shape or add an expression index, not another prayer.

4. Seq Scan is not automatically the villain

A sequential scan on a 200-row lookup table is the correct plan. Postgres knows it, and you should let it. The seq scan becomes the villain in exactly one situation: it is scanning a large table and throwing almost all of it away.

Rows Removed by Filter is the field that tells you. If a seq scan reads a million rows and the filter removes 999,996 of them, that is either a missing index or an index the query cannot use. Check whether the filtered column has an index. If it does and Postgres still chose the seq scan, the estimate was probably wrong (see section 3) or the filter is not sargable, like a function call wrapping the column.

Small table, full scan: fine. Big table, filter discards everything: that is your problem.

5. Nested loops: the silent killer

Nested loop joins are perfect when the outer side is small. Ten outer rows, index probe each, done. They become catastrophic when the outer side grows and nobody notices, because the plan shape does not change, only the loop count does. A query that ran fine for a year starts timing out, and the plan looks "the same" except loops= went from 50 to 500,000.

My rule: if the outer side returns more than a few thousand rows, I want a hash join or a merge join, not a nested loop doing random I/O per row. The fix is usually upstream, make the outer side smaller (a better filter, a better estimate), rather than forcing the join type.

6. Hash joins, sorts, and work_mem

When a hash join or a sort does not fit in work_mem, Postgres spills to disk. The plan tells you plainly:

Sort Method: external merge  Disk: 18432kB

or for a hash join, multiple batches instead of one. Disk is orders of magnitude slower than memory, and this is the easiest big win in query tuning: SET LOCAL work_mem = '256MB' for that session or transaction and re-run. If the plan flips to an in-memory quicksort and the time collapses, you found it.

I do not raise work_mem globally for this. It is per-operation memory, and a global bump gets multiplied by every concurrent sort and hash in the system. Session-local, for the query that needs it, is the disciplined move.

7. Index-only scans and heap fetches

An index-only scan is Postgres's cheapest access path, but it has a catch: it still visits the table (the heap) for any row whose visibility is not confirmed in the visibility map. The plan shows this as Heap Fetches. A high number means the table is not vacuumed often enough and the "index-only" scan is quietly doing heap I/O anyway.

If you see an index-only scan with thousands of heap fetches on a table that updates a lot, the fix is not a better index. It is autovacuum tuning, or a manual VACUUM, so the visibility map actually reflects reality.

8. CTEs can be an optimization fence

On Postgres 12 and later, a CTE that is referenced once gets inlined into the main query like a subquery, and the planner can optimize across it. Before 12, every CTE was materialized: fully computed, stored in a temp table, then read. That fence still exists on demand with the MATERIALIZED keyword.

When I see a plan where a CTE materializes millions of rows and the outer query filters down to a hundred, I check whether inlining would let the planner push the filter inside. On modern Postgres this usually happens automatically, but a MATERIALIZED left over from an older version, or a CTE referenced twice, will still fence it. Small thing, big difference on large CTEs.

9. My 60-second routine for any slow query

This is the actual order I go in, every time:

Find the node with the largest exclusive time (subtract children, multiply loops). That is the bottleneck. Everything else is context.
On that node and its parents, compare estimated rows to actual rows. A big gap means fix statistics or query shape before touching anything else.
Check BUFFERS on the expensive nodes. Mostly reads means a caching problem, not a plan problem.
Look for disk: external merge, hash batches, temp files. That is work_mem, session-local.
Check the join strategy against the outer row count. Nested loop with a huge outer side is the usual suspect for queries that "used to be fast."

Most slow queries I have chased were not exotic. A wrong estimate, a missing index, or a nested loop that outgrew its welcome. The plan tells you which one in about a minute, if you read it bottom-up and trust the numbers over your first guess.

Redis in Production: What I Actually Configure

Parsa Aftabi — Mon, 12 Oct 2026 18:43:09 +0000

Redis in Production: What I Actually Configure

Redis is the piece of infrastructure everyone under-configures. Out of the box it's a cache with no memory limit, an eviction policy that fails writes instead of evicting, and persistence that can lose your last chunk of data. That's fine on a laptop. In production, the defaults will page you at 3am.

Here's what I actually touch on every Redis I ship, and why. None of it is exotic — that's the point.

1. maxmemory + maxmemory-policy: the two lines that matter most

Default Redis has no memory limit and noeviction. When memory fills up, writes start failing with OOM errors while reads keep working. That's the worst kind of failure: half your app looks fine, the other half is quietly dropping writes.

I always set maxmemory — below what the box actually has, leaving headroom for fragmentation and the OS — and I pick the policy based on what that Redis instance is for:

Pure cache: allkeys-lru. Least-recently-used keys go first. Simple, correct for a cache.
Sessions or mixed data with TTLs: volatile-lru (or volatile-ttl if you'd rather evict nearest-expiry first).
Queue or anything you can't afford to lose: noeviction is actually right here. I'd rather have writes fail loudly than silently drop queued jobs. But then maxmemory must be sized so it never fills, and you monitor it like a hawk.

The mistake I keep seeing: one Redis doing all three jobs under one policy. Separate your concerns — or at least know exactly which data you're willing to lose.

2. Persistence: decide what "losing it" means

Redis gives you RDB snapshots, an AOF log, or nothing. The default is RDB snapshots only, which means you can lose everything since the last snapshot.

Pure cache: persistence off is fine, and it's faster. Losing a cache is a cold start, not an incident. Write that in the runbook so nobody panics at 4am.
Anything you can't rebuild (sessions you don't want to nuke, queues, rate-limit state): AOF with appendfsync everysec. You lose at most a second of writes, and the performance cost is boring.
Belt and suspenders: run both. AOF wins on restart; RDB gives you fast point-in-time copies for disaster recovery.

Whatever you choose: test the restart. I've seen more Redis "data loss" caused by nobody ever testing failover than by actual crashes.

3. Timeouts: reap the dead connections

Idle client connections pile up. Every app server that connected once and never said goodbye stays on the list. timeout 300 closes idle clients (the default is 0 — never — which is a slow leak). tcp-keepalive 300 lets the OS reap dead peers instead of holding their slots forever.

If your CLIENT LIST keeps growing week over week while traffic is flat, this is why.

4. slowlog: your free query profiler

slowlog-log-slower-than 10000
slowlog-max-len 128

Then actually read it: SLOWLOG GET. What I'm looking for isn't one slow command — it's the same command showing up hundreds of times. That's your N+1 wearing a Redis costume.

Usual suspects: KEYS * in production (use SCAN), giant hashes fetched whole instead of with HSCAN, and Lua scripts that quietly grew teeth over six months of "just one more line."

5. Key discipline: TTLs or it didn't happen

Every key gets a TTL unless you can articulate why not. Keys without expiry are how a cache becomes a memory leak with extra steps.

Here's the trap: volatile-lru and volatile-ttl only evict keys with a TTL. Keys without one are immortal — they will eventually OOM your instance no matter what policy you set. This is the single most common Redis misconfiguration I run into: policy set to volatile-lru, half the keys with no TTL, surprise OOM at 3am.

Two more habits: name keys like paths (service:entity:id) so SCAN is actually usable, and watch out for big keys. A 50MB hash is a latency bomb — on eviction, on replication, on HGETALL. Keep hashes small; split them.

6. Disable the footguns

rename-command FLUSHDB ""
rename-command FLUSHALL ""

Nobody needs to flush a production database on a whim and a redis-cli. Same treatment for KEYS and DEBUG in prod. Then the network basics: protected-mode yes, bind to the private interface only, requirepass set. Redis with no password on a reachable interface isn't a misconfiguration — it's an incident waiting for a scanner.

7. What I actually monitor

You don't need forty metrics. The ones that have ever paged me usefully:

used_memory vs maxmemory (as a percentage — alert before it matters)
evicted_keys rate (a spike means the working set doesn't fit, or TTLs are missing)
instantaneous_ops_per_sec (baseline it; deviations mean something changed upstream)
connected_clients and blocked_clients (blocked > 0 for a long time means something's stuck on BLPOP)
rdb_last_bgsave_status / aof_last_rewrite_status (persistence failing silently is the classic)
keyspace hits/misses (hit rate dropping means your cache isn't caching)

8. Replication: the minimum viable setup

One replica. replica-serve-stale-data yes — serve reads during failover instead of erroring everything. If you genuinely can't afford to lose writes during a partition, min-replicas-to-write — with the honest caveat that you're trading away availability.

For most services I run, an async replica plus good monitoring beats a fancy Sentinel setup nobody will maintain. If you need real HA with automatic failover, that's a different article — and honestly, probably a managed service.

None of this is exotic. Redis in production is mostly about deciding what each instance is for, setting boundaries (memory, TTLs, timeouts), and turning off the defaults that assume a laptop. Do that, and Redis disappears into the background — which is exactly where infrastructure belongs.

Docker Images I'd Actually Ship: A Production Checklist

Parsa Aftabi — Mon, 12 Oct 2026 09:17:04 +0000

Most Dockerfiles I've seen in the wild are development artifacts wearing a production costume. Someone took the image they debugged with, slapped a CMD on it, and called it a deploy. It works — right up until it doesn't: 1.2GB images, root processes, secrets baked into layers, and deploys that take ten minutes to pull.

Building a production image is a different discipline. Here's my checklist, the stuff I actually do on every service I ship, PHP or Go.

Multi-stage builds are the whole game

If you take one thing from this article, take this. A builder stage with your full toolchain, a runtime stage with almost nothing:

# ---- builder ----
FROM php:8.3-cli AS builder
RUN apt-get update && apt-get install -y git unzip \
    && rm -rf /var/lib/apt/lists/*
COPY --from=composer:2 /usr/bin/composer /usr/bin/composer
WORKDIR /app
COPY composer.json composer.lock ./
RUN composer install --no-dev --optimize-autoloader --no-interaction
COPY . .
RUN composer dump-autoload --optimize

# ---- runtime ----
FROM php:8.3-fpm
WORKDIR /var/www
COPY --from=builder /app /var/www
# ... config, permissions, user

Composer, git, build tools — none of that belongs in the image your users' requests hit. The runtime stage should contain your code, your runtime, and nothing else. This one change usually cuts image size by more than half.

Pick your base image like an adult

Three options, three personalities:

Alpine: tiny, fast pulls. But musl instead of glibc, which means the occasional weird DNS or binary-compat surprise at 2am. Fine for Go. I'd think twice for PHP with compiled extensions.
Debian slim: boring in the best way. glibc, everything behaves like your dev machine. Slightly bigger. This is my default for PHP.
Distroless / scratch: no shell, no package manager, no attack surface to speak of. Perfect for a statically compiled Go binary. Terrifying to debug — which is the point, because there's nothing to debug in.

My defaults: php:8.3-fpm (debian-based) for PHP, gcr.io/distroless/static for Go. Boring choices that don't page me.

Order your layers for the cache

Docker caches layers top-down, and every COPY invalidates everything below it. So: dependencies first (they change rarely), source code last (it changes constantly).

COPY go.mod go.sum ./
RUN go mod download
COPY . ./
RUN CGO_ENABLED=0 go build -o /app/server ./cmd/server

go mod download on its own layer means a code change doesn't re-download the world. Same idea with composer.json/composer.lock before the full source copy. Get this wrong and every deploy rebuilds everything from scratch while your CI bill quietly grows.

Run as non-root. No exceptions.

A container running as root that escapes is a host compromise. A container running as nobody that escapes is a bad day. The fix is one line and some permission hygiene:

RUN chown -R www-data:www-data /var/www/storage /var/www/bootstrap/cache
USER www-data

Do it after everything that needs root (installs, chowns), as late as possible in the Dockerfile. If your app can't run without root, that's a bug in your app, not a reason to skip this.

.dockerignore — the file everyone forgets

Without it, your build context includes .git, vendor/, node_modules/, your designer's 400MB of PSDs, and last year's backup. Slow builds, bloated contexts, and occasionally secrets you didn't mean to ship.

.git
vendor/
node_modules/
.env
*.md
docker-compose*.yml

Five minutes, once. There's no excuse.

Healthchecks that actually check something

HEALTHCHECK --interval=30s --timeout=3s --start-period=10s --retries=3 \
  CMD wget -qO- http://localhost:8080/health || exit 1

"Port is open" is not a health check. Your /health endpoint should verify what the app actually needs: can it reach the database, is Redis responding, is the disk writable. A container that accepts traffic while its DB connection is dead is worse than a container that's down — at least a down container gets restarted.

Secrets don't go in images. Ever.

Build args, ENV lines with passwords, .env files copied into the image — all of these end up in layer history, readable by anyone who can pull the image. I've seen production AWS keys in public images. Don't be that team.

Secrets arrive at runtime: environment variables from your orchestrator, mounted secret files, a vault agent. The image should boot with zero credentials and complain loudly if they're missing. Fail fast on missing config is a feature.

PHP specifics

Leave xdebug at home. It's a dev extension. It slows every request and has no business in production. --no-dev on composer, no dev extensions in the runtime stage.
Tune OPcache in the image, not on the server. opcache.enable=1, opcache.validate_timestamps=0 (you redeploy instead of editing files on the box, right?), generous opcache.memory_consumption.
One process per container. PHP-FPM in one container, nginx in another. Or skip the pair entirely — FrankenPHP serves a Laravel app from a single image with no FPM/nginx split, and it's genuinely simpler to operate.

Go specifics

This is where Docker shines brightest:

FROM golang:1.24 AS builder
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o /server ./cmd/server

FROM gcr.io/distroless/static:nonroot
COPY --from=builder /server /server
USER nonroot:nonroot
ENTRYPOINT ["/server"]

A static binary, no libc, no shell, running as nonroot. The final image is ~15MB. Fifteen. Compare that to the 1GB PHP-FPM image you started with and tell me Go doesn't earn its reputation.

The numbers

The pattern repeats everywhere: single-stage images with dev dependencies and no .dockerignore routinely land in the 1GB+ range. Rebuild the same app multi-stage — slim runtime, no dev deps, non-root, tuned OPcache — and it lands an order of magnitude smaller, typically well under 200MB. Pull time goes from minutes to seconds, which matters a lot when you're scaling up under load.

The checklist

Multi-stage build. Boring base image. Deps before source in layer order. Non-root user. A real .dockerignore. Healthchecks that check dependencies. Secrets only at runtime. No dev tools in the runtime stage.

None of this is exotic. That's the point — production Docker isn't about clever tricks, it's about doing the boring things consistently. The teams that get paged at 3am are usually the ones that skipped the boring things.

Laravel Octane in Production: What the Docs Don't Tell You

Parsa Aftabi — Sun, 11 Oct 2026 10:57:56 +0000

Laravel Octane promises something that sounds too good: your Laravel app, running at speeds that make PHP-FPM look like it's wading through mud. Thousands of requests per second. Response times in single-digit milliseconds.

It's real. I've seen it. But between the marketing and your production server there's a gap the docs gloss over, and it's full of memory leaks, stateful landmines, and 3am restarts. Here's what I actually learned running Octane for real.

Pick your server like it matters, because it does

Octane gives you three engines: FrankenPHP, Swoole, and RoadRunner. The docs present them as roughly equal choices. They're not.

FrankenPHP is what I'd hand to most teams. It's a Caddy-based app server, installs without drama, and worker mode just works. If your team already deploys PHP the boring way, this is the smallest jump with the biggest payoff.

RoadRunner is the grown-up in the room. Written in Go, mature process model, great supervisor story. If you want boring reliability and you don't mind one more binary in your stack, it's hard to beat.

Swoole is the fastest on paper and the one I'd least like to debug at 3am. It's a PHP extension that rewrites the rules of the runtime — coroutines, its own event loop, its own table implementation. When it works it's beautiful. When it doesn't, you're reading C-level stack traces wondering where your evening went.

My take: start with FrankenPHP. Move to RoadRunner if you outgrow it or need its process model. Only reach for Swoole if you know exactly why you need it.

Your app is stateful and you forgot

This is the big one. Under PHP-FPM, everything dies at the end of every request. Your sloppy singleton? Gone. That static property accumulating data? Gone. FPM is a garbage collector with a web server attached.

Octane keeps your app booted in memory across requests. Suddenly all that state you were accidentally relying on FPM to clean up... doesn't get cleaned up.

The classic hits:

// This looks innocent. Under Octane it's a memory leak with a login form.
class ReportService
{
    protected static array $rows = [];

    public function addRow(array $row): void
    {
        static::$rows[] = $row; // grows forever, across requests, across users
    }
}

Singletons bound with request-scoped data. Event listeners registered in a service provider that never get deregistered. Config values mutated at runtime (config(['app.timezone' => ...]) in one request leaking into the next). Locale or timezone set per-request and never reset.

The fix isn't complicated, but it requires a mindset shift: treat every request as sharing a room with every other request. Audit your singletons. Prefer bind() over singleton() for anything request-scoped. And use Octane's lifecycle hooks — Octane::tick(), request "flush" callbacks — to reset what must not survive.

If your codebase is old and nobody knows what the singletons hold, be honest with yourself: Octane will find every one of them, in production, on a Friday.

Memory leaks are not an if, they're a when

Even a clean app leaks a little under a long-lived worker. A few kilobytes per request doesn't matter at 100 requests. At 100,000 requests on the same worker, it matters a lot.

So don't run workers forever. Octane lets you cap it:

// config/octane.php
'max_requests' => 500, // recycle the worker after 500 requests

Pick a number and stop theorizing. 500 is a fine default. Watch worker memory in your monitoring — if it climbs steadily between recycles, you have a leak worth hunting. If it stays flat, your number is fine and you can raise it.

And set up octane:reload as part of your deploy, not as an afterthought. A deploy that doesn't recycle workers is a deploy that didn't fully happen.

Concurrency is a tool, not a lifestyle

Octane can run tasks concurrently (Octane::concurrently()), and it's genuinely useful for the fan-out pattern: three independent API calls, one response. I've replaced whole queue jobs with it where the work was fast and the user was waiting anyway.

But don't turn your request lifecycle into a concurrency puzzle. If you need real background work with retries and failure handling, that's what queues are for. Octane doesn't replace Horizon. It replaces the part of your code that was waiting on I/O for no reason.

Deploy it like a grown-up

A few things that bite people on day one:

Supervisor (or systemd) is not optional. Workers die. OOM-killer exists. Your process manager should restart them without you noticing. Here's the shape of it:

[program:octane]
command=php /var/www/artisan octane:start --server=frankenphp --workers=auto --max-requests=500
autostart=true
autorestart=true
user=www-data

--workers=auto is a starting point, not an answer. Start there, then size workers to your actual CPU and memory. More workers than cores just adds context-switching overhead.
OPcache + preloading still matter. Octane doesn't make PHP's compilation cost disappear for free; keep your OPcache tuned like you would anywhere else.
Warm your caches before traffic arrives. First requests on fresh workers are the slowest. A deploy-time warmup script hitting your key routes saves you from a latency spike right when you're watching the dashboards.

When I'd skip Octane entirely

Not every app should run on it, and saying so isn't heresy:

Low-traffic apps where FPM is already idle 99% of the time. You're adding operational complexity for numbers nobody will notice.
Apps with heavy per-request memory (big file processing, huge collections) — long-lived workers amplify this instead of containing it.
Codebases where nobody will fix the leaks Octane exposes. The server is honest; your app has to be too.

Octane is a performance tool for apps that have outgrown FPM's model, not a magic flag you flip on everything.

The verdict

Octane is the real deal — the performance gains aren't marketing. But it's a different runtime model wearing Laravel's clothes, and it demands you actually understand what your app holds in memory.

Do the singleton audit. Cap your worker lifetimes. Pick FrankenPHP unless you have a reason not to. Deploy with a process manager and a reload strategy from day one.

Get those right and Octane is the easiest performance win in the Laravel ecosystem. Get them wrong and you'll learn about memory leaks the hard way — which, to be fair, is also a way to learn.

PostgreSQL Connection Pooling in Go: What I Actually Tune in Production

Parsa Aftabi — Sat, 10 Oct 2026 19:56:33 +0000

In my last post, lesson 3 was "your database is the bottleneck, not Go" — use pgx, size the pool deliberately. A few of you asked what "deliberately" actually means. Fair question.

Here's every pgxpool setting I touch in production, what it does, and the number I actually use. No theory — just the config running behind real traffic.

1. The pool is the choke point, not your code

Go will happily spin up 10,000 goroutines to serve requests. If your pool holds 20 connections, 9,980 of those goroutines are standing in line doing nothing.

Every performance problem I've debugged in a Go API eventually led here. Not the handler, not the JSON serialization — the pool. It's the narrowest pipe in your system, and the defaults are not your friend. Every setting below is about controlling that pipe.

2. MaxConns: do the math, per instance

Each Postgres connection costs the server a backend process — a few MB of memory plus CPU spent context-switching. Past a few hundred connections, Postgres spends more time managing connections than running queries. More connections is not more throughput; it's more overhead.

The formula I use, per API instance:

max_conns ≈ (2 × CPU cores) + 4

A 4-core box gets 12. Not 100. Not unlimited. 12.

Why 2×? Web queries are I/O-bound — while one connection waits on disk, another uses the CPU. Two per core keeps the CPU busy without drowning Postgres in backends. The +4 is headroom for migrations, admin queries, and that one endpoint that fans out.

The part everyone misses: multiply by instance count. Three replicas × 12 = 36 connections hitting Postgres. Five services each with a pool of 20 = 100 backends before a single query runs. I size the pool backwards, from the database's perspective: database connection budget ÷ number of clients = per-instance MaxConns.

config, err := pgxpool.ParseConfig(connStr)
if err != nil {
    log.Fatal(err)
}
// sized: (2 × 4 cores) + 4. Database budget ÷ instances.
config.MaxConns = 12

3. MinConns: idle is not free

MinConns keeps warm connections ready so a traffic burst doesn't pay connection-setup latency. Sounds great until you realize every idle connection still holds a Postgres backend process. MinConns = 10 across ten instances is 100 backends doing absolutely nothing at 3 AM.

I keep it small — 2 to 5. Enough to absorb a burst, cheap enough to forget about. pgx ramps up to MaxConns on demand anyway, and the ramp is fast. Warm is good; hoarding is not.

config.MinConns = 2

4. The two settings everyone ignores: lifetimes

Long-lived connections go stale. Load balancers silently drop idle TCP connections. DNS changes don't propagate to connections that are already open. A statement_timeout you changed on the server only applies to new connections.

config.MaxConnLifetime = time.Hour        // recycle every connection hourly
config.MaxConnIdleTime = 30 * time.Minute // reap connections idle this long

MaxConnLifetime forces rotation — no connection lives long enough to go quietly stale. MaxConnIdleTime reaps connections that are just sitting there holding a backend for no reason.

One gotcha: don't set MaxConnLifetime too aggressively. One minute on a busy pool means constant churn — TLS handshake and auth on every cycle. An hour is boring. Boring is good.

5. HealthCheckPeriod: trust, but verify

pgx validates idle connections before handing them out, but only as often as HealthCheckPeriod allows. The default is one minute, which is fine for most setups.

If your network is flaky — cloud load balancers love silently killing idle TCP — drop it to 30 seconds. It's a cheap ping. A dead connection handed to a live request is an expensive 500.

config.HealthCheckPeriod = time.Minute

6. Fail fast: the context deadline is your acquire timeout

This is the setting that saves you during an outage. When the pool is exhausted, what should the 21st request do — wait forever, or fail fast?

pgx v5 has no separate acquire-timeout knob. Connection acquisition respects the context deadline. Your context timeout is your acquire timeout. Use it:

ctx, cancel := context.WithTimeout(r.Context(), 2*time.Second)
defer cancel()

var name string
err := pool.QueryRow(ctx, "SELECT name FROM users WHERE id = $1", id).Scan(&name)

Two seconds, then the request fails with a clear error instead of piling up behind a dead database. This is the difference between "the API is slow" and "the API is down for everyone, including the health check." Fail fast, return 503, let the load balancer route around you.

7. Watch the pool: `pool.Stat()`

If you're not watching the pool, you're guessing. pgx exposes everything:

s := pool.Stat()
log.Printf("pool: total=%d idle=%d acquired=%d max=%d",
    s.TotalConns(), s.IdleConns(), s.AcquiredConns(), s.MaxConns())

I export these as Prometheus gauges and alert on exactly one thing: AcquiredConns sitting at MaxConns. That means the pool is saturated — every new request is queueing. It tells me to scale instances or find the slow query holding connections hostage, long before users notice.

Two patterns I watch in dashboards:

IdleConns near zero with TotalConns at MaxConns — the pool is too small, or something is leaking connections.
AcquireCount climbing far faster than actual queries — something acquires and never releases. Nine times out of ten, it's a forgotten rows.Close().

8. Mistakes I've actually made

A pool per request. Early on I called pgxpool.New inside a handler "to be safe." Every request built a pool, every pool opened connections. The database fell over in minutes. One pool per process, created at startup, passed down. Ever.

Forgetting pool.Close(). On shutdown, in-flight queries get killed mid-flight and the database logs a wall of errors. Close the pool in your graceful shutdown path — after srv.Shutdown, before exit. (See lesson 6 of my last post.)

Prepared statements behind PgBouncer in transaction mode. pgx prepares statements by default; PgBouncer in transaction-pooling mode can't handle named prepared statements across transactions, and you'll get prepared statement already exists errors at the worst possible time. The fix is one line:

config.ConnConfig.DefaultQueryExecMode = pgx.QueryExecModeSimpleProtocol

Only needed if you run PgBouncer in transaction mode. If you don't know what that means, you probably don't — skip it.

9. The config I actually ship

package platform

import (
    "context"
    "log"
    "time"

    "github.com/jackc/pgx/v5/pgxpool"
)

func NewPool(ctx context.Context, connStr string) *pgxpool.Pool {
    config, err := pgxpool.ParseConfig(connStr)
    if err != nil {
        log.Fatalf("parse db config: %v", err)
    }

    config.MaxConns = 12
    config.MinConns = 2
    config.MaxConnLifetime = time.Hour
    config.MaxConnIdleTime = 30 * time.Minute
    config.HealthCheckPeriod = time.Minute

    // Only if you run PgBouncer in transaction mode:
    // config.ConnConfig.DefaultQueryExecMode = pgx.QueryExecModeSimpleProtocol

    pool, err := pgxpool.NewWithConfig(ctx, config)
    if err != nil {
        log.Fatalf("create db pool: %v", err)
    }

    // Fail fast at startup if the database is unreachable.
    pingCtx, cancel := context.WithTimeout(ctx, 5*time.Second)
    defer cancel()
    if err := pool.Ping(pingCtx); err != nil {
        log.Fatalf("ping database: %v", err)
    }

    return pool
}

Twelve connections. Two idle minimum. Hourly rotation. And a ping at startup, so a bad connection string fails the deploy — not the first request at 2 AM.

Connection pooling is unglamorous work. Nobody demos a pool config. But it's the difference between an API that degrades gracefully and one that falls over the first time traffic spikes.

What's your MaxConns, and how did you arrive at it? I'm curious whether anyone actually measures this or just copies 20 from a tutorial.

I write about backend engineering, Go, and the unglamorous work of keeping systems alive. Follow for more.

7 Lessons I Learned Building Production APIs in Go

Parsa Aftabi — Fri, 09 Oct 2026 13:57:37 +0000

TL;DR: After shipping several production systems in Go – coming from PHP/Laravel – these are the eight lessons that actually mattered: boring project structure, context.Context everywhere, fixing the database before adding cache, deliberate Redis caching, request-ID logging, graceful shutdown, and thin handlers. Code included.

When I first picked up Go, I came from PHP/Laravel land – where the framework holds your hand through everything. Go handed me a toolbox, pointed at the horizon, and said "good luck."

A few production systems later, here are the eight lessons that actually stuck. Not theory – the stuff I wish someone had told me on day one.

1. Boring project structure beats clever frameworks

My first Go API had packages named utils, helpers, and common – three junk drawers with the same junk. Don't do that.

What works: organize by domain, keep main.go thin, and resist importing a web framework until net/http genuinely hurts.

/cmd/api/main.go
/internal/user/handler.go
/internal/user/service.go
/internal/user/repository.go
/internal/platform/db/
/internal/platform/cache/

Boring is a feature. The next person reading your code (probably future you at 2 AM) will thank you.

2. `context.Context` is not optional

Every handler, every DB call, every outbound request should take a context. The day a slow downstream service hangs your entire API is the day you learn this the hard way. Learn it the easy way:

ctx, cancel := context.WithTimeout(r.Context(), 3*time.Second)
defer cancel()

user, err := repo.GetByID(ctx, id)

Three lines. Timeouts, cancellation, and request-scoped values – all from threading ctx through your call chain.

3. Your database is the bottleneck, not Go

Go can handle tens of thousands of concurrent requests. Your Postgres connection pool cannot – at least not with default settings.

Use pgx with a properly sized pool, and size it deliberately:

pool, err := pgxpool.New(ctx,
    "postgres://user:pass@localhost:5432/app?pool_max_conns=20&pool_min_conns=5")

Rule of thumb I follow: max_connections ≈ (2 × CPU cores) + a small buffer per instance. And add the missing index before you add Redis. Most "slow API" problems I've debugged were a missing index, not a missing cache.

4. Cache deliberately with Redis – don't sprinkle it everywhere

Caching everything is how you get stale data bugs that only appear on Tuesdays. I cache with two rules:

Cache-aside only – the app reads from cache, falls back to DB, and writes back. No magic.
Every cached key gets a TTL and an invalidation story. If you can't explain when the key expires or gets invalidated, don't cache it.

// cache-aside in ~10 lines
if val, err := rdb.Get(ctx, key).Result(); err == nil {
    return val, nil // cache hit
}
val, err := db.Query(ctx, ...) // cache miss: go to source
if err == nil {
    rdb.Set(ctx, key, val, 5*time.Minute)
}
return val, err

5. Structured logging with request IDs will save you

log.Println("something happened") is a confession, not logging. In production you need to trace one request across handlers, DB calls, and cache lookups. The cheapest way: a request-ID middleware plus structured logs.

// a private key type keeps request-scoped values collision-free across packages
type ctxKey string

const requestIDKey ctxKey = "requestID"

func requestID(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        id := uuid.NewString()
        w.Header().Set("X-Request-ID", id)
        ctx := context.WithValue(r.Context(), requestIDKey, id)
        next.ServeHTTP(w, r.WithContext(ctx))
    })
}

The typed key matters: a plain "requestID" string key can be silently overwritten by another package's middleware using the same string. Two extra lines, zero collisions.

Then log with fields, not sentences: logger.Info("order.created", "request_id", id, "order_id", orderID). When something breaks at 3 AM, you'll grep one ID instead of reading 50,000 lines.

6. Handle graceful shutdown from day one

It's ten lines of code, and it prevents dropped requests on every deploy:

quit := make(chan os.Signal, 1)
signal.Notify(quit, syscall.SIGINT, syscall.SIGTERM)
<-quit // wait for shutdown signal
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
defer cancel()
if err := srv.Shutdown(ctx); err != nil {
    log.Fatalf("forced shutdown: %v", err)
}

In-flight requests finish, DB connections close cleanly, and your deploys stop causing mysterious 502s.

7. Keep handlers thin – they're translators, not business logic

A handler should do three things: parse input, call a service, write output. The moment you see SQL queries or business rules inside a handler, extract them.

// handler: translation layer only
func (h *Handler) CreateUser(w http.ResponseWriter, r *http.Request) {
    var in CreateUserInput
    if err := json.NewDecoder(r.Body).Decode(&in); err != nil {
        writeError(w, http.StatusBadRequest, err)
        return
    }
    user, err := h.service.CreateUser(r.Context(), in)
    if err != nil {
        writeError(w, http.StatusInternalServerError, err)
        return
    }
    writeJSON(w, http.StatusCreated, user)
}

All the real logic lives in service. Handlers stay dumb, services stay testable.

8. Set server timeouts — the defaults are zero

Go's http.Server ships with no timeouts at all. A client that drips one byte per minute can hold a connection open indefinitely — this is how Slowloris works, and how "the API just stopped responding" incidents begin. Timeouts are load-bearing config; review them the way you review your pool size.

srv := &http.Server{
    Addr:         ":8080",
    Handler:      router,
    ReadTimeout:  10 * time.Second,  // max time to read the whole request
    WriteTimeout: 30 * time.Second,  // max time to write the whole response
    IdleTimeout:  120 * time.Second, // max idle time on keep-alive connections
}

One subtlety worth knowing: WriteTimeout starts counting when the headers are read, not when your handler starts — so for long-lived streaming endpoints (SSE, downloads), set it generously or manage it per-handler.

I extracted this exact setup into a tiny library — graceful. Same defaults, plus SIGINT/SIGTERM handling and ordered shutdown hooks. Zero dependencies.

The thread connecting all eight

None of these are about Go-specific tricks. They're about respecting production: timeouts, observability, clean boundaries, deliberate caching. Go just happens to make the right thing easy – if you let it.

Which lesson hit home for you? And what's the one you wish someone told you on day one? I'd genuinely like to steal it for the next post. 👇

I write about backend engineering, Go, and the unglamorous work of keeping systems alive. Follow for more.

DEV Community: Parsa Aftabi

Read the migration before production does: miglens, a local-AI migration-risk explainer in Go

What I Built

Demo

Code

How I Built It

Why Does Open Innovation Matter?

The Spirit of It

My logs never leave the box: logwhisper, a local-AI log explainer in Go

What I Built

Demo

Code

How I Built It

Why Does Open Innovation Matter?

The Lazy Payoff

The http.Server Setup I Use in Every Go Project — Now Open Source

The stdlib defaults are a footgun

The setup

Shutdown hooks, in order

What it deliberately doesn't do

Try it

PostgreSQL EXPLAIN ANALYZE: What I Actually Look At in Query Plans

PostgreSQL EXPLAIN ANALYZE: What I Actually Look At in Query Plans

1. Always add BUFFERS

2. Read bottom-up, and multiply by loops

3. Estimated rows vs actual rows: the gap is the signal

4. Seq Scan is not automatically the villain

5. Nested loops: the silent killer

6. Hash joins, sorts, and work_mem

7. Index-only scans and heap fetches

8. CTEs can be an optimization fence

9. My 60-second routine for any slow query

Redis in Production: What I Actually Configure

Redis in Production: What I Actually Configure

1. maxmemory + maxmemory-policy: the two lines that matter most

2. Persistence: decide what "losing it" means

3. Timeouts: reap the dead connections

4. slowlog: your free query profiler

5. Key discipline: TTLs or it didn't happen

6. Disable the footguns

7. What I actually monitor

8. Replication: the minimum viable setup

Docker Images I'd Actually Ship: A Production Checklist

Multi-stage builds are the whole game

Pick your base image like an adult

Order your layers for the cache

Run as non-root. No exceptions.

.dockerignore — the file everyone forgets

Healthchecks that actually check something

Secrets don't go in images. Ever.

PHP specifics

Go specifics

The numbers

The checklist

Laravel Octane in Production: What the Docs Don't Tell You

Pick your server like it matters, because it does

Your app is stateful and you forgot

Memory leaks are not an if, they're a when

Concurrency is a tool, not a lifestyle

Deploy it like a grown-up

When I'd skip Octane entirely

The verdict

PostgreSQL Connection Pooling in Go: What I Actually Tune in Production

1. The pool is the choke point, not your code

2. MaxConns: do the math, per instance

3. MinConns: idle is not free

4. The two settings everyone ignores: lifetimes

5. HealthCheckPeriod: trust, but verify

6. Fail fast: the context deadline is your acquire timeout

7. Watch the pool: pool.Stat()

8. Mistakes I've actually made

9. The config I actually ship

7 Lessons I Learned Building Production APIs in Go

1. Boring project structure beats clever frameworks

2. context.Context is not optional

3. Your database is the bottleneck, not Go

4. Cache deliberately with Redis – don't sprinkle it everywhere

5. Structured logging with request IDs will save you

6. Handle graceful shutdown from day one

7. Keep handlers thin – they're translators, not business logic

7. Watch the pool: `pool.Stat()`

2. `context.Context` is not optional