Plataforma de notificações multicanal_

Trabalho num app mobile bancário de um cliente do setor financeiro. O app acompanha o cliente por uma jornada com várias etapas, e o negócio queria falar com ele em algumas delas, no momento certo.

A comunicação com o cliente era pouca e dependia de muito esforço manual. O negócio queria falar com ele automaticamente em etapas específicas da jornada.

Contratar uma solução externa seria lento, difícil e caro nesse contexto. Construir a nossa saía mais barato.

Arquitetei e construí a plataforma sozinho, do zero ao fim: defini quais serviços existem, o que cada um faz e como eles conversam, e implementei cada um deles. O desenho já prevê como ela cresce.

São três peças, cada uma com uma responsabilidade:

• Perfil de notificação. Uma API que guarda os canais que o cliente cadastrou e as preferências dele.
• Orquestrador. Uma API que recebe os eventos da jornada, aplica o template certo e envia para os canais cadastrados no perfil do cliente.
• Um adapter por provedor. FCM para push, e-mail e WhatsApp, cada um atrás do seu adapter. O envio não depende de nenhum provedor específico.

As notificações são configuráveis, com perfis, categorias e templates reutilizáveis, e cada mensagem tem retry com um tempo de vida (TTL) próprio.

Hoje os eventos chegam por uma API REST. O desenho já está pronto para trocar essa entrada por uma fila quando o volume crescer.

1. 01

   Construir em vez de comprar

   Para esse cliente, contratar uma solução de mercado era lento, difícil e caro. Construir saiu mais barato. Em troca, a plataforma passa a ser nossa para manter.

2. 02

   Um adapter por provedor

   O envio fica desacoplado dos provedores de cada canal: cada provedor tem o seu adapter. Adicionar ou trocar um provedor não afeta o resto da plataforma.

3. 03

   Retry com TTL por mensagem

   Uma mensagem que já não faz sentido para o cliente não deve ser reenviada para sempre. Por isso cada mensagem tem um tempo de vida: enquanto ela vale, o envio é tentado de novo; depois disso, para.

4. 04

   Perfil separado do envio

   Os canais e as preferências do cliente ficam numa API própria. O orquestrador consulta o perfil para decidir para onde enviar, mas não é dono desses dados.

5. 05

   REST primeiro, fila depois

   Uma API REST resolve o volume de hoje. A troca por uma fila ficou prevista no desenho, para quando o volume crescer.

Mais agilidade para o time de Growth e comunicação personalizada com o cliente. A comunicação passou a ser automática nas etapas certas da jornada, com menos trabalho manual e um custo menor do que comprar uma solução de mercado.

Levar a entrada de eventos para uma fila quando o volume pedir; o desenho já conta com essa mudança. E, se um canal ou provedor novo aparecer, ele entra como mais um adapter.