Resource limits enforced on workers
Why it matters
A queue worker with no memory limit can consume all available host memory during a burst, taking down the database, Redis, and web server on the same host. CWE-400 (uncontrolled resource consumption) applies directly. The connection pool problem is multiplicative: 5 replicas with a default pg connection pool of 10 connections each create 50 connections — fine for one replica, catastrophic for five on a database with a max_connections of 25. ISO 25010 performance-efficiency.resource-utilization requires that resource consumption is bounded and predictable.
Severity rationale
Low because resource limits protect co-located services from worker memory exhaustion and connection pool saturation, but the failure mode is gradual rather than instantaneous.
Remediation
Add memory limits at the container level and set explicit connection pool sizes. In docker-compose.yml:
services:
email-worker:
mem_limit: 512m
environment:
- DATABASE_POOL_SIZE=5 # 5 per instance × replicas
And in the worker startup command:
node --max-old-space-size=400 dist/worker.js
Calculate pool size as: floor(max_connections / expected_replicas). At least 2 of 3 resource limits — memory, DB connection pool, Redis connection pool — must be explicitly configured.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Operational Resilience (Email) Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- cwe · CWE-400 — Uncontrolled Resource Consumption — unbounded worker memory and connection pools exhaust host resources
- iso-25010:2011 · performance-efficiency.resource-utilization — Performance Efficiency / Resource Utilisation — explicit memory and connection limits required
Taxons
History
- 2026-04-18·v1.0.0·Initial import from operational-resilience-email·automated