System Design/04 - Cloud Design Patterns/Data Management2 min
Valet Key
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Dar ao cliente um token de acesso limitado e temporário que o autoriza a falar diretamente com o armazenamento — sem que o dado atravesse a aplicação.
sem valet key: cliente → aplicação → armazenamento (a app carrega os bytes)
com valet key: cliente → aplicação → token
cliente → armazenamento (direto)
Implementações: URL pré-assinada do S3, SAS token do Azure, URL assinada do Google Cloud Storage.
O token é escopado: um objeto específico, uma operação específica (leitura ou escrita), e um prazo curto.
Trade-offs
O ganho é eliminar a aplicação do caminho dos bytes. Um upload de 2 GB que passaria pela aplicação consome banda, memória e uma thread por toda a duração — exatamente o Busy Frontend. Com valet key, a aplicação gasta milissegundos gerando um token.
O custo é perder o controle sobre o que acontece durante a transferência:
| Perde | Consequência |
|---|---|
| Validação de conteúdo | Não dá para inspecionar o arquivo em trânsito |
| Antivírus / moderação | Precisa ser feito depois, por evento |
| Controle de tamanho preciso | Depende do que o armazenamento oferece |
| Log unificado | O acesso fica no log do armazenamento |
Por isso o padrão quase sempre vem acompanhado de processamento assíncrono: o upload dispara um evento, e um worker valida, escaneia e move o arquivo para o local definitivo.
O risco de segurança é o vazamento do token. As mitigações: prazo curto (minutos, não horas), escopo mínimo (um objeto, uma operação), restrição por IP quando possível, e nunca reutilizar o mesmo token.
E um detalhe frequentemente esquecido: a URL assinada aparece em logs de proxy, histórico de navegador e referrers. Prazo curto é o que limita o dano.
Exemplo prático
Upload de vídeo de 2 GB.
1. POST /videos/upload-url
→ a aplicação valida permissão, gera URL assinada
(PUT, 15 min, um objeto específico, tamanho máximo)
2. o cliente envia os 2 GB direto para o armazenamento
3. o armazenamento emite evento de objeto criado
4. um worker valida, transcodifica e publica
A aplicação nunca vê os 2 GB. Ela participa em dois momentos, cada um com custo desprezível: autorizar e, depois, reagir ao evento.
A alternativa — proxiar o upload — consumiria uma thread por três minutos e limitaria a plataforma a poucos uploads simultâneos por instância.
Relacionado
Parte de Data Management · roadmap.sh/system-design