Pular para o conteúdo
#0097
DaemonContainers

Each customer's worker lives in their own container

Your SaaS runs background jobs per customer. The shared-worker design has become a permanent ops problem: one tenant's runaway job starves the queue, you can't isolate failures, billing CPU per tenant is guesswork.

Each customer container runs its own daemon-supervised worker. One JSON config per tenant: their command, their user, their auto-restart policy, their environment. The worker process is bound to the tenant's container: its CPU, its memory, its filesystem. When tenant 47's worker crashes into FATAL, tenant 48's worker keeps running on the same metal next door, untouched.

A noisy tenant can't starve a quiet one: they don't share a process table. Worker logs land in the tenant's own container. Restart latency is 200ms. Idle tenants cost zero CPU.

The multi-tenant queue stopped being a queue. It became 80 single-tenant queues that share metal, not state.