Onde usar? | etcd | Banco de Dados
- Onde usar? | etcd | Banco de Dados
Você deve usar etcd quando precisa de um banco chave-valor distribuído, consistente e confiável para guardar dados pequenos, críticos e usados para coordenação entre serviços.
Ele não é um banco de aplicação comum. Pense nele como um cérebro de coordenação do cluster, não como banco principal de negócio.
Onde faz sentido usar etcd
1. Configuração distribuída
Use etcd para guardar configurações que vários serviços precisam ler de forma consistente.
Exemplo:
etcdctl put /apps/payment/feature-pix-enabled true
etcdctl put /apps/payment/max-retries 3
etcdctl put /apps/payment/timeout-ms 5000
Depois a aplicação lê:
etcdctl get /apps/payment/feature-pix-enabled
Contexto típico:
Vários serviços precisam consumir a mesma configuração.
A configuração pode mudar em runtime.
Você quer evitar redeploy só para mudar parâmetros.
Exemplos reais:
- timeout de chamadas externas
- limite de retry
- endpoint ativo de algum serviço
- percentual de rollout
- configuração por ambiente
- parâmetros operacionais
2. Service Discovery
Use etcd para registrar onde os serviços estão rodando.
Exemplo:
etcdctl put /services/orders/instance-1 "http://10.0.0.11:8080"
etcdctl put /services/orders/instance-2 "http://10.0.0.12:8080"
Um consumidor pode buscar:
etcdctl get /services/orders --prefix
Contexto típico:
Serviços sobem e descem dinamicamente.
Você precisa descobrir instâncias disponíveis.
Não quer hardcoded IP no código.
Isso é comum em sistemas de infraestrutura, clusters, schedulers e plataformas internas.
3. Leader Election
Use etcd quando vários processos estão rodando, mas apenas um deles deve executar uma tarefa crítica.
Exemplo de contexto:
Tenho 5 réplicas do mesmo worker.
Apenas uma pode executar o job de conciliação.
Se a líder morrer, outra assume.
Casos reais:
- scheduler distribuído
- batch crítico
- job recorrente
- consumidor exclusivo
- controlador de cluster
- processamento que não pode duplicar
Exemplo conceitual:
/app/jobs/consolidacao/leader = worker-3
Se worker-3 morrer, o lease expira e outro worker tenta virar líder.
4. Distributed Lock
Use etcd para criar locks distribuídos quando múltiplas instâncias podem tentar executar a mesma operação.
Contexto:
Tenho várias instâncias da API.
Uma operação não pode ser executada em paralelo.
Preciso garantir exclusividade temporária.
Exemplo de chave:
/locks/processar-arquivo-123
Casos reais:
- impedir processamento duplicado
- garantir exclusividade em job
- evitar múltiplas migrações simultâneas
- controlar acesso a recurso compartilhado
A diferença para leader election é:
| Caso | Uso |
|---|---|
| Leader Election | Escolher uma instância líder por tempo indeterminado |
| Distributed Lock | Bloquear uma operação específica temporariamente |
5. Controle de estado de cluster
etcd é muito usado para guardar estado de infraestrutura.
Exemplo:
/nodes/node-1/status = healthy
/nodes/node-2/status = draining
/nodes/node-3/status = offline
Contextos:
- orquestradores
- sistemas de cluster
- control planes
- plataformas internas
- health/status de nós
- estado desejado vs estado atual
O Kubernetes usa etcd exatamente para guardar o estado do cluster.
Exemplo conceitual:
Estado desejado:
- quero 3 réplicas do serviço A
Estado atual:
- existem 2 réplicas saudáveis
Controlador:
- cria mais 1 réplica
6. Feature Flags simples
Você pode usar etcd como backend simples para feature flags.
Exemplo:
etcdctl put /features/new-checkout/enabled true
etcdctl put /features/new-checkout/percentage 10
Contexto:
Quero ligar/desligar comportamento sem redeploy.
Quero que múltiplas instâncias enxerguem a mesma flag.
Quero propagação rápida.
Mas atenção: para feature flags complexas, com segmentação por usuário, auditoria, UI, regras e experimentos A/B, ferramentas próprias como LaunchDarkly, Unleash ou OpenFeature podem ser melhores.
7. Watch de alterações
Um dos pontos fortes do etcd é o watch.
Você pode observar mudanças em uma chave ou prefixo:
etcdctl watch /apps/payment/timeout-ms
Ou observar um prefixo inteiro:
etcdctl watch /apps/payment --prefix
Contexto:
Minha aplicação precisa reagir quando uma configuração mudar.
Não quero ficar fazendo polling toda hora.
Exemplo:
Mudou /apps/api/rate-limit
A aplicação recebe o evento
Atualiza a configuração em memória
Isso é útil para:
- reload de configuração
- troca de endpoint ativo
- circuit breaker operacional
- feature flags
- descoberta de serviços
- controle de cluster
8. Leases / TTL
Use lease quando uma chave deve existir apenas enquanto um processo estiver vivo.
Exemplo conceitual:
/services/worker/instance-1 = 10.0.0.5
TTL = 30 segundos
Se o worker morrer e parar de renovar o lease, a chave expira.
Contextos:
- service discovery
- presença de nós
- locks temporários
- leader election
- heartbeat distribuído
Isso evita sujeira no cluster, porque registros mortos somem automaticamente.
Onde não usar etcd
1. Não use como banco relacional
Não use etcd para:
clientes
pedidos
produtos
pagamentos
notas fiscais
logs de negócio
histórico transacional
Para isso use PostgreSQL, MySQL, MongoDB, SQL Server etc.
2. Não use para dados grandes
etcd não foi feito para payload grande.
Evite guardar:
- JSON gigante
- arquivos
- imagens
- relatórios
- blobs
- documentos grandes
- payloads de comandos SQL grandes
O ideal é guardar valores pequenos, geralmente configurações, metadados e estado de coordenação.
3. Não use como fila
Não use etcd como RabbitMQ, Kafka, NATS ou Redis Streams.
Ele até permite observar mudanças com watch, mas isso não transforma o etcd em broker de mensageria.
Evite usar etcd para:
fila de pedidos
fila de eventos
stream de logs
mensageria entre microsserviços
processamento assíncrono pesado
Para isso, use:
| Necessidade | Ferramenta melhor |
|---|---|
| Mensageria tradicional | RabbitMQ |
| Streaming/eventos | Kafka |
| Pub/Sub leve | NATS |
| Stream simples | Redis Streams |
| Jobs assíncronos | Hangfire, Quartz, BullMQ, Celery |
4. Não use para cache comum
etcd não substitui Redis.
Não use para:
- cache de resposta HTTP
- cache de sessão
- cache de consulta
- cache de objeto grande
- cache de alta volumetria
Para cache, use Redis, Memcached ou cache local.
5. Não use para alta taxa de escrita
etcd prioriza consistência. Cada escrita precisa passar pelo consenso do cluster.
Então ele não é ideal para:
milhares de writes por segundo de dados de aplicação
eventos de telemetria
logs
métricas
rastreamento de usuário
Para isso, use bancos ou brokers próprios para volume.
Regra prática
Use etcd quando a pergunta for:
Vários nós precisam concordar sobre um estado pequeno e crítico?
Se sim, etcd pode fazer sentido.
Não use etcd quando a pergunta for:
Preciso guardar dados de negócio?
Preciso guardar muito volume?
Preciso fazer queries complexas?
Preciso de fila?
Preciso de cache?
Aí provavelmente não é etcd.
Exemplos bons de uso
| Cenário | etcd faz sentido? | Motivo |
|---|---|---|
| Guardar configuração global da aplicação | Sim | Dados pequenos e críticos |
| Escolher um worker líder | Sim | Coordenação distribuída |
| Criar lock entre múltiplas instâncias | Sim | Controle de concorrência |
| Descobrir instâncias ativas de serviços | Sim | Service discovery |
| Guardar estado de um cluster | Sim | Estado consistente |
| Guardar pedidos de clientes | Não | Dado de negócio |
| Guardar logs da aplicação | Não | Volume alto |
| Guardar cache de API | Não | Redis é melhor |
| Guardar eventos de integração | Não | Kafka/RabbitMQ/NATS são melhores |
| Guardar arquivos JSON grandes | Não | Não é storage de documento pesado |
Exemplo de árvore de chaves
Uma organização comum seria:
/config
/api
/timeout-ms
/max-retries
/rate-limit
/payment
/pix-enabled
/provider-active
/services
/orders
/instance-1
/instance-2
/payments
/instance-1
/locks
/job-conciliacao
/processar-arquivo-123
/leaders
/scheduler
/payment-worker
/features
/new-checkout
/enabled
/percentage
Exemplo prático
Gravar configuração:
etcdctl --endpoints=http://127.0.0.1:2379 \
put /config/api/timeout-ms 5000
Ler:
etcdctl --endpoints=http://127.0.0.1:2379 \
get /config/api/timeout-ms
Observar mudança:
etcdctl --endpoints=http://127.0.0.1:2379 \
watch /config/api/timeout-ms
Atualizar:
etcdctl --endpoints=http://127.0.0.1:2379 \
put /config/api/timeout-ms 8000
Buscar tudo de um prefixo:
etcdctl --endpoints=http://127.0.0.1:2379 \
get /config --prefix
Minha recomendação prática
Use etcd para estes 4 contextos principais:
| Prioridade | Contexto |
|---|---|
| 1 | Configuração distribuída |
| 2 | Leader election |
| 3 | Distributed locks |
| 4 | Service discovery / presença de instâncias |
Evite usar etcd como banco principal da aplicação. Ele é excelente para coordenação, não para persistência geral de negócio.