Worker Processes

• A master process binds the listening socket and forks N workers, each a full copy of the application with its own memory, its own connections and its own event loop or thread pool (Accepting Connections).
• Workers share the listening socket, so the kernel distributes accepted connections among them. Which worker gets which connection is the kernel's or the runtime's decision, and it is not perfectly even.
• On a fork-based system, the children initially share the parent's memory pages copy-on-write. In practice the savings erode as each worker writes — in CPython, even reading an object touches its reference count, so shared pages are copied sooner than the model suggests.
• Isolation is the second benefit and often the bigger one: a worker that crashes, leaks or segfaults takes down one of N. The master restarts it and the service stays up (Error Boundaries: Three Translations, Not One).
• Everything per-process is now per-worker: connection pools, in-memory caches, rate-limit counters, scheduled timers, warm JIT state, prepared statements. Multiply before deploying.
• A graceful reload works by starting new workers and retiring old ones once they finish their in-flight requests, which is how a process manager achieves a zero-downtime restart on one machine (Graceful Shutdown).
• In a container-orchestrated deployment this same choice appears one level up: N workers inside one container, or N containers with one worker each. The multiplication arithmetic is identical; the operational story is not (Containerizing a Backend).

Instances (or pods)         :  6
Workers per instance        :  8
Pool size per worker        : 10
---------------------------------------------------
Connections to the database : 6 x 8 x 10 = 480
Postgres max_connections    : 100                <-- refused, hard

And remember the ones that are NOT the database:
  in-memory caches           : 48 independent caches
  scheduled jobs             : each cron entry fires 48 times
  in-process rate limits     : published limit x 48
  memory                     : 8 x per-worker heap, per instance

Fixes, in the order to try them:
  1. shrink pool per worker   (10 -> 2)   => 96 connections
  2. move the schedule out of the process entirely
  3. move counters and locks to a shared store
  4. put a connection proxy (e.g. PgBouncer) in front of the database
  5. only then reconsider the worker count itself

• Compute the fan-out explicitly: instances x workers x pool size, checked against the database's connection limit, before the first deploy. Write it down somewhere that gets reviewed (Connection Pool Exhaustion).
• Shrink the per-worker pool as you add workers. Eight workers with a pool of two is often better than two workers with a pool of eight, because the constraint is total connections, not per-worker capacity.
• Move anything that must happen once out of the workers: scheduled jobs to a scheduler or a leader-elected job, counters and locks to a shared store (Atomic Operations).
• Handle SIGTERM in the worker: stop accepting, finish in-flight requests, close pools, then exit — and make sure the grace period exceeds your longest normal request (Graceful Shutdown).
• Create connections after the fork, never before. A file descriptor shared across processes by forking is a corruption bug that appears under load (Connection Pools).
• Set worker recycling (max_requests with jitter, or a maximum age) as a containment measure for slow leaks, and keep looking for the leak (Memory Leaks in Backend Services).
• Decide deliberately between "N workers in one container" and "N containers with one worker": one container per worker gives the orchestrator direct control over scheduling and limits; N workers per container amortises the base image and startup cost (Deployment Models).