Uma fila que cresce durante uma campanha pode ter diversas causas. O aplicativo pode estar produzindo correspondência mais rápido do que o seu provedor aceita, o provedor pode estar retardando a entrega ou um sistema de recebimento pode estar adiando destinos específicos. Chamar todos os três de “estrangulamento Gmail ” esconde a localização do gargalo.
Localize o primeiro estágio atrasado
Referências: RFC 5321 §4.2.1, RFC 5321 §4.5.4.1.
Capture carimbos de data/hora para criação de trabalho, envio do fornecedor, aceitação do fornecedor e cada tentativa de entrega. Preservar o texto completo da resposta e o sistema que a emitiu. Uma resposta bem-sucedida da API do aplicativo não é o mesmo evento que o servidor receptor final aceita uma mensagem. Se o provedor não expor um estágio, marque-o como indisponível em vez de inferir um carimbo de data/hora exato.
SMTP distingue respostas negativas temporárias de respostas negativas permanentes. Uma resposta temporária não é uma orientação para tentar novamente continuamente a toda velocidade; o sistema de envio precisa de uma fila e de uma política de repetição apropriada. Uma falha permanente não deve ser tratada como um acúmulo temporário e interminável. RFC 5321 seções 4 e 4.5.4.
Inspecione a carga de trabalho alterada
Compare o mix de destinos, mensagens únicas e tentativas. Uma campanha que envia muitas tentativas pode aumentar a contagem de tentativas sem representar destinatários adicionais. Separe os trabalhos de marketing das mensagens transacionais sensíveis à latência e verifique se elas competem pela mesma simultaneidade ou orçamento de taxa.
O Google aconselha evitar picos e aumentar o tráfego gradualmente enquanto monitora as respostas. Aplique as orientações atuais Gmail ao escopo declarado, em vez de traduzi-las em um limite universal seguro de mensagens por segundo. Nenhum número público neste artigo pode certificar a capacidade de um remetente. Diretrizes para remetentes Gmail.
Trabalhe a aritmética da fila
Referências: RFC 5321 §4.2.1.
O modelo sintético local começa com uma fila vazia. Novos trabalhos chegam a 120 mensagens por minuto, enquanto a taxa de serviço presumida é de 80 por minuto durante dez minutos. A lista de pendências aumenta 40 por minuto, para 400 mensagens. Se as chegadas forem pausadas e a mesma taxa de serviço continuar, o tempo de drenagem idealizado será de cinco minutos.
Isso é aritmética de fila, não um limite medido do provedor ou uma previsão de recuperação em tempo real. Exclui deliberadamente novas tentativas, expiração e alterações nas taxas de serviço. Essas omissões explicam por que uma fila real pode demorar mais. Preserve as suposições juntamente com o cálculo para que uma planilha de capacidade não se torne uma promessa de nível de serviço sem suporte.
O modelo determinístico de estado de resposta retido, executado novamente off-line para esta revisão, mantém um registro de tentativas. Às 09:00 UTC, um trabalho com script recebe “451 4.7.0 Limite de taxa temporário; tente novamente mais tarde”. Seu estado se torna nova tentativa pendente, o fluxo afetado é marcado para pressão reduzida e uma nova tentativa local controlada às 09h30 recebe “250 2.0.0 Aceito”. Outro trabalho recebe “550 5.1.1 Nenhum destinatário” às 09:00 e entra em falha permanente sem nova tentativa; sua próxima ação é a verificação do destinatário aprovado. Essas respostas completas são entradas de teste locais inventadas. Trinta minutos é a configuração de nova tentativa deste aparelho, não uma instrução universal do provedor. O código deriva transições de estado de classes de resposta e proíbe uma segunda tentativa não planejada.
Reduza a pressão sem perder a correção
Referências: RFC 5321 §4.5.4.1.
Pause ou reduza o fluxo não essencial afetado por meio do agendador aprovado. Deixe a fila responsável repetir falhas temporárias usando sua política suportada. Evite criar uma segunda fila que reenvie a mesma transação porque um painel está atrasado. Use identificadores de transação estáveis para reconciliar resultados de envio incertos.
Para mensagens urgentes, siga a rota de continuidade aprovada somente após verificar a autenticação e a prevenção de duplicatas. Não alterne a infraestrutura para evitar uma restrição do provedor. Escale com carimbos de data/hora, texto de resposta, escopo de destino, identificadores de rota e evidências da alteração corretiva.
Retomar a expansão quando o atraso e a distribuição etária se estabilizarem sob uma carga de trabalho legítima definida. Continue verificando as mensagens mais antigas: um atraso médio baixo pode ocultar um pequeno grupo de redefinições ou recibos muito atrasados.