System Design/05 - Reliability Patterns/Availability2 min
Deployment Stamps
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Replicar unidades independentes e completas do sistema (stamps, ou células), cada uma atendendo um subconjunto de clientes.
stamp 1: [app + banco + cache] → clientes A-F
stamp 2: [app + banco + cache] → clientes G-M
stamp 3: [app + banco + cache] → cliente-grande (dedicado)
Um roteador direciona cada cliente ao seu stamp. Os stamps não compartilham nada.
Trade-offs
O ganho central é o raio de explosão. Com três stamps, uma falha atinge um terço dos clientes — não todos. Com dez, um décimo.
Isso muda também a forma de publicar: um deploy pode ir para um stamp por vez, e um problema afeta apenas aquele grupo. É deploy canário com granularidade de infraestrutura, não de tráfego.
E resolve Noisy Neighbor de forma estrutural: clientes de stamps diferentes não compartilham recurso nenhum. Um cliente grande pode ganhar um stamp dedicado.
Os custos são reais:
| Custo | Detalhe |
|---|---|
| Sem economia de escala | Cada stamp tem sua infraestrutura completa |
| Operação multiplicada | N ambientes para publicar, monitorar e migrar |
| Roteamento | Alguém precisa saber onde cada cliente está |
| Migração entre stamps | Rebalancear é uma operação de dados |
| Consultas globais | Um relatório de todos os clientes atravessa N bancos |
A automação deixa de ser opcional: provisionar e publicar em dez stamps manualmente é inviável, e o padrão só funciona com infraestrutura como código.
O critério de adoção é quando o raio de explosão ou o isolamento entre clientes vale mais que a eficiência de recursos — tipicamente em SaaS com clientes grandes, ou onde a indisponibilidade total é inaceitável.
Exemplo prático
Um SaaS com 5.000 clientes distribuídos em cinco stamps de mil.
Um deploy defeituoso derruba o stamp 3. Mil clientes são afetados; quatro mil continuam operando normalmente — e o rollback é de um ambiente, não de todos.
Um cliente que sozinho representa 30% da carga recebe um stamp dedicado. Ele deixa de competir com os demais, e sua eventual sobrecarga não sai do próprio ambiente.
O preço aparece no relatório consolidado mensal, que precisa consultar cinco bancos e agregar — e na necessidade de que todo o provisionamento seja automatizado.
Relacionado
Parte de Availability · roadmap.sh/system-design