Quem já lançou um bot no Discord já viu isso: uma terça-feira normal e, de repente, increased api errors em toda parte e metade dos seus comandos falhando. O Google Trends registrou a expressão como um termo de pesquisa em "alta" em meados de 2026; ela acontece com frequência suficiente para que os usuários finais a pesquisem diretamente. Veja como sobreviver a isso e o que a API de Servidor da Noxyr aproveita dessas lições.

A request gets a 429, waits out a countdown, then retries and succeeds with a 200. Server 429 200 3 2 1 Retry-After

Os três maiores modos de falha da API do Discord

  • Queda global / queda parcial: visível em discordstatus.com. Sintomas: qualquer requisição pode falhar, o gateway pode cair, a latência dispara em todo lugar.
  • 429 Too Many Requests: você excedeu o limite de um bucket. O Discord retorna um cabeçalho Retry-After informando exatamente quanto tempo esperar.
  • Sessão inválida no gateway: sua sessão WebSocket está obsoleta. Reconecte com o seu resume token; se isso falhar, faça um novo identify.

Projete para falhas, não para dias ensolarados

  • Respeite o Retry-After. Não tente de novo no seu próprio cronômetro. Espere exatamente o tempo que o Discord informar e então tente uma vez. Bots que insistem após 429s são banidos.
  • Backoff exponencial com jitter. Em erros 5xx, espere 1s, 2s, 4s, 8s, mais um pequeno deslocamento aleatório para que uma frota de reinicializações não gere um pico simultâneo.
  • Interrompa chamadas não críticas com circuit breaker. Se o seu bot publica um resumo semanal e a API do Discord está degradada, pule essa execução em vez de sobrecarregar ainda mais. O resumo pode esperar; a queda não.
  • Guarde em cache tudo que não é em tempo real. Nomes de servidores, listas de canais, IDs de cargos: armazene-os localmente. Durante uma queda, os dados em cache mantêm o seu serviço funcionando.
  • Mostre o status. Se os comandos do seu bot estão falhando porque o Discord está fora do ar, avise os usuários. Uma linha como "O Discord está enfrentando problemas no momento" é melhor do que timeouts silenciosos.

Como a API de Servidor da Noxyr aplica essas lições

A API de Servidor da Noxyr não é a API do Discord; ela lê o próprio banco de dados, mas os mesmos princípios se aplicam e moldaram o seu design:

  • Erros previsíveis: toda falha é JSON com um código error estável. Nada de HTML, nada de formatos variáveis.
  • Cabeçalhos de limite de taxa: cabeçalhos padronizados RateLimit-*, para que os clientes recuem antes de atingir um 429.
  • Degradação graciosa: o endpoint /api/v1/server recorre aos dados de servidor em cache quando a busca no Discord falha.
  • Sem falhas em cascata: cada endpoint falha de forma independente. Se o Discord estiver fora do ar, isso não quebra o seu endpoint de análise de tickets, porque ele lê do Mongo, não do Discord.
  • Interruptor de emergência instantâneo: desativar uma chave ou um escopo tem efeito já na próxima requisição, sem precisar reiniciar nada.

Roteiro quando o Discord dá problema

  • 1. Verifique primeiro em discordstatus.com: é só com você?
  • 2. Analise os seus próprios logs de erro: 429s, 5xx, desconexões do gateway.
  • 3. Se for o Discord: pause as escritas não críticas, respeite o Retry-After e aguarde.
  • 4. Se for você: verifique deploys recentes, invalidações de cache e novos recursos.
  • 5. Comunique. Um aviso curto e honesto no seu canal de suporte evita 100 relatos duplicados.

Mais sobre a camada de API: a API de Servidor da Noxyr, API do Discord vs API da Noxyr, princípios de design de API.