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.

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.

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.

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.

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 seven 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:

1. Cache-aside only — the app reads from cache, falls back to DB, and writes back. No magic.

2. 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.

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(), "requestID", id)
        next.ServeHTTP(w, r.WithContext(ctx))
    })
}

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.

The thread connecting all seven

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.

Originally published at https://dev.to/parsaaftabi/7-lessons-i-learned-building-production-apis-in-go-35f9