The shared inbound relay for every customer domain runs as one pod with no durable queue and no rate limits. It already throttled once. This proposes a two-tier Postfix split that fixes both — without adding a new stateful dependency, and without exceeding Hetzner's per-node volume ceiling.
Proactive hardening, not incident response — but CPUThrottlingHigh already fired once, on 2026-07-14, and the fix applied was a one-time vertical bump, not a structural one.
replicas: 1, no HPA anywhere in infra/mail-proxy. Every connection for every customer domain funnels through one pod.
mynetworks = 0.0.0.0/0, smtpd_relay_restrictions = permit. A burst has no degrade-gracefully path — just CPU starvation. Same root cause as the open-relay posture.
Spool lives on the pod's writable layer. Any message between accept and durable commit is lost on crash — and that window scales with throughput, not just backend-outage duration.
dovecot-imap (client-pull) shares a replica count with the SMTP relay (sender-push) for no technical reason.
Traefik matches HostSNI(*) on ports 25 / 587 / 143 and routes all of it to a single ClusterIP-backed pod.
Every customer's inbound mail and IMAP traffic depends on this one pod being up. A crash between accept and delivery loses whatever was in flight.
Tier 1 scales freely and holds nothing. Tier 2 is small, fixed, and durable — reusing Postfix's own native retry/bounce logic instead of building new state machinery.
250 OK is only sent after durable commit — to the backend, or to Tier 2. A Tier 1 crash before that point means the original sender's own MTA never got 250 and retries on its own.
No longer shares a replica count or a pod with the SMTP relay.
Verified live, 2026-07-16. This node is already close to the ceiling from ordinary customer PVC growth (established by #505). A design that scales PVC count 1:1 with relay replicas competes directly with that headroom — which is why Tier 2's PVC count is fixed, not proportional to Tier 1's replica count.
| Option | Verdict | Why |
|---|---|---|
| Two-tier Postfix | chosen | Reuses Postfix's own proven retry/backoff/bounce logic. Fixed PVC count regardless of Tier 1 replicas. No new stateful dependency. |
| N PVCs, one per replica | rejected | Scales PVC consumption 1:1 with replica count — directly collides with the 16/node ceiling and ordinary customer growth. |
| Redis / DB-backed queue | rejected | Achieves the same fixed-storage outcome, but means hand-rebuilding retry backoff and RFC 3464 bounce generation against a new dependency that doesn't exist in this cluster yet. |
| Stalwart central mail tier (#502) | closed | Bigger idea — retires per-customer volumes entirely. Explicitly declined: newer, not proven at scale, at the exact layer where failure means silently lost mail. |
| Dedicated ingress per dominant tenant | deferred | No evidence of a noisy-neighbor problem today. Named as an escape hatch, not built. |