Product
Atualização semanal de produto: notificações melhoradas para limites de e-mails
O Mailgun permite enviar milhões de e-mails por mês. Mas, para muitos profissionais de desenvolvimento que estão criando o próximo aplicativo de dominação mundial, isso é muito para começar. Para facilitar sua vida se você usa nosso plano gratuito para testes e desenvolvimento ou uma plataforma como Heroku ou EngineYard que impõe um limite ao volume de e-mails mensal, nós melhoramos as notificações de e-mail para que você receba um alerta antes de atingir o limite.
As notificações de e-mail agora alertam você antes de atingir o limite
Se você está em um plano do Mailgun com um limite de envio explícito, nós sempre enviamos uma notificação de e-mail depois que o limite de e-mails é atingido. No entanto, isso não dá muito tempo para você se planejar. Por isso, a partir desta semana, também começaremos a enviar notificações quando você estiver perto do seu limite. Especificamente,
- Clientes do nosso plano gratuito recebem notificações depois de atingirem 75% do limite diário
- Demais clientes em planos limitados (como Heroku ou EngineYard) recebem notificações ao atingirem 75% e 95% do limite mensal
É uma pequena melhoria, mas esperamos que ela ajude você a se planejar melhor para a dominação mundial.
Se você tem interesse em saber como criamos notificações voltadas para confiabilidade e escala, esta próxima parte é para você
Enviar uma notificação quando um cliente atinge 75% do seu limite de envio parece fácil e, conceitualmente, é. O que foi um desafio, no entanto, foi transformar isso em um sistema confiável e escalável que funciona bem para milhares de clientes enviando milhões de e-mails por dia. Quando analisamos o problema pela primeira vez, adotamos a abordagem óbvia: adicionar um campo ao nosso banco de dados de clientes baseado em MongoDB e aumentar o contador a cada e-mail enviado.
Mas quando percebemos a carga que isso colocaria no nosso MongoDB (que não funciona bem com um número tão alto de gravações por segundo), sabíamos que precisávamos de uma abordagem diferente.
Um sistema baseado em atores separa processos para um melhor desempenho
Em vez de complicar nosso banco de dados principal, no qual gostamos de gravar apenas quando é absolutamente necessário, nós implementamos um sistema baseado em atores que separa a maioria dos eventos do nosso banco de dados principal. Ao separar eventos em sistemas especializados diferentes, o Mailgun se torna muito mais eficiente, resiliente e fácil de programar. Há muitos motivos para isso. Um deles é que processos diferentes podem ser executados em máquinas diferentes, ou seja, se houver um problema em um processo, o outro não será afetado. Como isso funciona?
O Mailgun é basicamente apenas uma série de eventos. Entregas. Devoluções. Aberturas. Cliques. Quando qualquer um desses eventos acontece, nós os registramos. Em seguida, é possível configurar processos diferentes para fazer algo com esses eventos. Por exemplo, quando acontece um evento de “entregue”, temos um processo capaz de notificar um cliente por webhook.
Ou, no caso das notificações de limites de e-mail, funciona assim:
- O Mailgun entrega e recebe e-mails, o que gera eventos.
- Cada um desses eventos é enviado ao Redis, um armazenamento de chave-valor excelente para a criação de filas de eventos.
- Depois, temos um processo separado — que chamamos de Watchdog — que apenas acompanha esses eventos e calcula coisas como se o cliente atingiu ou não o limite de e-mails do plano.
- Por fim, temos um outro processo que efetivamente envia a mensagem ou, em casos nos quais o cliente excedeu o limite, desativa a conta.
Cada processo faz uma única coisa muito bem. Existem poucas partes móveis e é fácil escalar. Lucro!
Bem, isso é tudo por esta semana. Esperamos que você goste das novas notificações de eventos e tenha aprendido um pouco sobre a forma como desenvolvemos no Mailgun.
Bons envios,
Os Mailgunners
