Sharding por tenant

O KumoMTA escala horizontalmente rodando vários nós independentes. Não há cluster integrado, então você faz o sharding antes dele (upstream), com hash por tenant ou por campanha.

Estrutura típica:

[ Application / API ]
        │
   shard router (HAProxy with consistent hash on header)
        │
   ┌────┼────┬────┬────┐
[node1] [node2] [node3] [node4]
   │      │      │      │
  IPs    IPs    IPs    IPs

Por que usar hash por tenant: todas as filas de um tenant ficam em um nó → throttling e aquecimento consistentes. Se um tenant crescer muito, mova-o para um par dedicado.

Trecho do HAProxy:

backend kumo_pool
  balance hdr(X-Kumo-Tenant)
  hash-type consistent
  server node1 10.0.0.11:587 check
  server node2 10.0.0.12:587 check
  server node3 10.0.0.13:587 check

A aplicação define o cabeçalho X-Kumo-Tenant no momento do SMTP (via XCLIENT ou metadados próprios do AUTH).