/projects/dietbox-notifications
← Todos os projetosDietbox Notifications
Uma conta de mensageria transformada em restrição de produto.
Head de Tecnologia · 2023–2024
Visão geral
Este serviço existe por causa de um número numa fatura: a conta de mensageria oficial do WhatsApp em maio de 2023. A resposta não foi um limite de taxa colado no produto existente, mas um pequeno domínio próprio — uma cota, um log de quem a alterou, e um registro de cada envio.
O que eu fiz
O documento de design, o domínio e o serviço são do autor: dezenove dos vinte commits, da primeira estimativa ao serviço em produção.
- O próprio documento de planejamento de capacidade — as estimativas de volume, taxa de consultas e armazenamento que o serviço foi construído para atender.
- O modelo de domínio: um limite de notificações por profissional, um log de cada mudança nele, e um registro de cada notificação enviada.
- Os dois controllers e seus comandos e queries — adicionar um limite, enviar uma notificação, e consultar tanto limites quanto registros enviados.
- Os pacotes transversais atrás das camadas: a integração com o provedor do WhatsApp e a injeção de dependência.
O problema
A conta oficial da API do WhatsApp Business chegou em maio de 2023, e o produto não tinha como medir o que estava gastando com ela. O lugar óbvio para adicionar um limite era o próprio produto principal — mas o produto principal já era complexo demais para ser estendido com segurança, e um controle de custo que arrisca o produto que está protegendo não é um controle de custo. A alternativa foi um serviço com zero impacto no produto, capaz de atender outros canais de notificação depois.
Em números
Esses quatro números vêm do próprio documento de design do serviço, escrito antes de existir uma linha dele — um plano de capacidade, não uma medição de produção feita depois.
Arquitetura
Um serviço chamador chega ao endpoint de notificação, que verifica a cota do profissional antes de qualquer envio, entrega a mensagem ao provedor, e registra o resultado de qualquer forma.
- Calling serviceOutro serviço da plataforma solicita uma notificação em nome de um profissional.
- Notify endpointO controller de notificação recebe a requisição e dispara o comando de envio.
- Quota checkO limite do profissional é lido antes de o envio prosseguir — sem cota, sem mensagem.
- ProviderA integração com o WhatsApp envia a mensagem pela API oficial, atrás do pacote transversal do provedor.
- Sent recordO resultado — enviado ou recusado — é gravado no registro que toda notificação deixa.
Uma notificação, do pedido ao registro
- RequestedUm serviço chamador pede o envio de uma notificação a um profissional.
- Quota checkedO limite restante do profissional é verificado contra o pedido.
- Dispatched or refusedDentro da cota, a mensagem segue para o provedor do WhatsApp; fora da cota, o envio é recusado antes de custar algo.
- RecordedQualquer resultado é gravado no log de notificações enviadas, então a resposta para "por que isso foi bloqueado" já existe.
O que faz
- Um controller de notificação e comandos para enviar uma notificação e para adicionar o limite de um profissional.
- Um controller de nutricionista e queries sobre o limite atual e o histórico de notificações enviadas desse profissional.
- Três modelos de domínio: o próprio limite de notificações, um log de cada mudança nele, e um registro de cada notificação enviada.
- Um serviço em camadas com pacotes transversais para o provedor do WhatsApp e injeção de dependência, mantidos separados do domínio que sustentam.
Decisões de engenharia
Um serviço separado especificamente para ser ignorável
O objetivo declarado era zero impacto no produto principal. Isolar o serviço de notificações significou que ele podia ser desligado, reimplantado ou reescrito sem derrubar o produto junto — o oposto de colar um limitador num código que já era complexo demais para tocar com segurança.
Uma cota é um modelo de domínio, não um rate limit
Um contador simples responderia apenas "esse envio pode acontecer". Em vez disso, o limite, um log de cada mudança nele, e um registro de cada envio respondem juntos uma pergunta mais difícil: por que este foi bloqueado, e quem alterou o limite que o bloqueou.
Capacidade planejada antes da primeira linha
O volume mensal, a taxa de consultas e o espaço ocupado em dez anos foram estimados no documento de design antes de o serviço ser construído, e é por isso que a decisão de armazenamento — quanto espaço isso jamais precisaria — foi uma pergunta entediante e já respondida, não uma surpresa.
Um provedor primeiro, a interface para mais
O WhatsApp foi a conta que originou tudo isso, então é o único provedor que envia hoje — mas email, SMS e push foram o formato que o domínio e a API foram desenhados para aceitar depois, sem que o modelo de cota ou o registro de envio precisassem mudar.