Just Ask
Ask me anything about software architecture, careers, PHP, Go and the craft of building software; I answer here, in the open, for everyone. (Page 5/6)
Whatever's on your mind, don't hold back. Questions reach me directly; I answer the good ones and publish them on this page. Your email is never published.
Turn on HTTP/2 now — multiplexing collapses your 4-5 parallel per-screen requests onto one connection and kills the need for domain sharding. For a mobile audience, HTTP/3 (QUIC) is the bigger win: it removes TCP head-of-line blocking and speeds up the handshake.
For a web/microservice fleet, Transaction mode — it returns the server connection to the pool at the end of each transaction, giving the highest reuse. The catch: it breaks protocol-level prepared statements and session state. Fix: disable client-side prepared statements or use PgBouncer 1.21+; keep `default_pool_size` sane.
For most greenfield projects the answer is no: start with a monolith, draw clean boundaries, and split out services only when the need to scale is real.
The problem is the app doesn't drain on SIGTERM. Fix the lifecycle: drain the LB first, stop accepting new requests, finish in-flight work within a deadline, then exit. In Go use `server.Shutdown(ctx)`, in Octane a graceful reload; align the platform's grace period with your longest drain.
Build one composite index for this query: equality columns first (`user_id`, `status`), then the ORDER BY column last (`created_at DESC`). That way the index satisfies both the filter and the sort, killing the Bitmap merge + Sort. Drop the single-column indexes it now covers.
The real problem is that the key falls off a cliff at the same instant. Two complementary fixes: a single-flight mutex lock so only the first request hits the DB, and probabilistic early expiration (XFetch) so the herd never converges on one instant. Add TTL jitter and serve-stale-while-revalidate so users never wait. Single-flight + jitter covers most cases; reach for XFetch when recompute is expensive.
GC pauses are a symptom; the real enemy is allocation rate. Reuse short-lived buffers/structs on the hot path with `sync.Pool`, run escape analysis (`-gcflags=-m`) and keep heap-bound values on the stack. Measure before/after with `pprof`. `GOGC`/`GOMEMLIMIT` make GC less frequent but won't fix a path allocating 50k times a second.
Don't guess, measure. In Octane the worker is long-lived, so anything that accumulates between requests leaks: ever-growing static caches, singletons holding request state, services rebound per request. Bisect to find the leak, then reset stateful objects in Octane's hooks. `max_requests` isn't the cure, it's a safety valve.
At 10k tenants, database-per-tenant doesn't scale operationally (10k migrations, 10k pools, 10k backups). The pragmatic answer: a shared DB with `tenant_id` everywhere + Postgres Row-Level Security so isolation lives in the DB. ORM scope as a defense layer; keep a path to promote a whale tenant to its own DB later.
Two separate concerns. Authenticity: verify the provider's HMAC signature over the RAW body with a constant-time compare, reject otherwise. Idempotency: persist the provider's event id with a UNIQUE constraint and do check-or-insert inside a transaction — the DB, not app logic, guarantees once-only. Verify signature → return 200 fast → enqueue the work.