System Design/04 - Cloud Design Patterns/Design & Implementation2 min
External Config Store
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Manter configuração fora do artefato de deploy, num repositório central acessível em tempo de execução.
aplicação → config store (Consul, Parameter Store, etcd, App Config)
O mesmo binário roda em qualquer ambiente; o que muda é a configuração que ele lê.
O que vive lá
Endpoints e strings de conexão, feature flags, limites e timeouts, parâmetros de negócio, credenciais (num cofre com criptografia).
O que caracteriza um bom config store
| Recurso | Por quê |
|---|---|
| Versionamento | Configuração é código; precisa de histórico e rollback |
| Recarga sem restart | Mudar timeout sem redeployar |
| Escopo por ambiente | Mesma chave, valores por ambiente |
| Criptografia e controle de acesso | Nem toda configuração é pública |
| Auditoria | Quem mudou o quê |
Trade-offs
O ganho principal é separar deploy de configuração: ajustar um limite deixa de exigir build e release.
Os custos:
Mais uma dependência crítica. Se o config store cai, a aplicação pode não subir. A mitigação é obrigatória: cache local do último valor válido e valores padrão embutidos, para que a aplicação continue funcionando com a configuração que já tinha.
Configuração vira mudança em produção sem pipeline. Alterar um valor pode derrubar o sistema tão rápido quanto um deploy ruim — e frequentemente sem revisão, sem teste e sem rollback fácil. Por isso configuração merece o mesmo tratamento que código: versionamento, revisão e capacidade de reverter.
Recarga dinâmica é sutil. Trocar um valor em tempo de execução exige que o código lide com a mudança de forma consistente — um timeout alterado no meio de uma operação, ou um pool redimensionado sob carga, pode produzir comportamento inesperado.
E o alerta de segurança: segredo não pertence a um config store comum. Ele pertence a um cofre com criptografia, rotação e auditoria próprias.
Exemplo prático
/app/prod/db/host = db-prod.interno
/app/prod/timeouts/api_ms = 5000
/app/prod/flags/novo_checkout = 0.05 ← 5% dos usuários
A última linha é a que mais rende: liberar uma funcionalidade para 5%, observar as métricas, e subir para 25% e 100% — ou voltar a zero em segundos, sem deploy.
O que fecha o desenho é o cache local: se o config store ficar indisponível, a aplicação continua com os valores que leu por último. Sem isso, um problema no armazenamento de configuração vira uma queda total.
Relacionado
Parte de Design & Implementation · roadmap.sh/system-design