A worker fleet where every tenant has its own Redis

Your B2B platform runs sixty enterprise tenants. Each tenant's data has compliance constraints: their queue can't share a Redis instance with another tenant's queue. The Kubernetes-and-namespaces design works, but each Redis is a real pod with overhead, and idle tenants still cost money.

Each tenant gets a container. Inside, three daemon programs: a Redis instance (priority: 1, boot-true), a worker process consuming from that Redis (priority: 10), and a metrics shipper (priority: 20). Per-tenant configuration lives in programs.json checked into the tenant template.

Sixty tenants, one bare-metal box. Idle tenants: the ones whose users haven't logged in today: cost zero CPU and a few megabytes of disk. Active tenants get a real Redis with no co-tenancy. A noisy queue can't reach a quiet tenant's data: the process tables don't intersect.