Arquitetura de Notificações Orientada a Eventos para Fintechs Brasileiras

No ecossistema financeiro brasileiro, latência é dinheiro. O usuário faz um Pix e espera a notificação ("Dinheiro enviado") em milissegundos. Se demora 10 segundos, ele acha que deu erro e liga para o suporte.

Para fintechs, o sistema de notificação não é "feature acessória", é core banking. E a única forma de escalar isso de forma resiliente é com uma Arquitetura Orientada a Eventos (Event-Driven Architecture - EDA).

O Problema do Monólito Síncrono vs. Event-Driven

O Risco do modelo síncrono: Se o provedor de SMS cair ou demorar (timeout), a transação Pix pode falhar ou ficar "pendurada" na visão do sistema, gerando inconsistência. O acoplamento é fatal.

A Solução: Events First (Fire and Forget)

No modelo event-driven, o serviço de Pix tem uma única responsabilidade: processar o Pix e emitir um evento: transaction.completed.

Arquitetura em Ação: Pix → Kafka → Notificação

Fluxo desacoplado:

1. Serviço de Pix processa transação e publica evento
2. Kafka distribui para consumidores (incluindo serviço de notificações)
3. Worker consome evento e formata mensagem
4. Gateway Notifica envia via canal preferido do usuário

Os Componentes

1. Event Bus (Kafka / RabbitMQ / SQS): A espinha dorsal. Recebe o evento transaction.completed com o payload (User ID, Valor, Data).
2. Notification Service (Consumer): Escuta este tópico. Ele é responsável por:
   • Orquestração: O usuário prefere Push, WhatsApp ou SMS?
   • Templating: Injeta os dados no texto ("Você recebeu R$ 50,00").
   • Roteamento: Envia para o Gateway (FCM, APNS, Twilio, Notifica).
3. Fallback Worker: Se o Push falhar (ex: token inválido), publica um novo evento push.failed que aciona o envio de um SMS ou WhatsApp como contingência.

Desafios Brasileiros: Pix e Fraude

No Brasil, temos dois cenários críticos:

1. Instantaneidade do Pix

O SLA de percepção do usuário é < 3 segundos.

• Dica: Priorize a fila de eventos de Pix (high-priority-queue) sobre eventos de Marketing (low-priority). Não deixe uma campanha de Black Friday atrasar notificações de saldo.

Sistema de Prioridades de Fila

2. Notificações de Fraude

Quando o motor de risco bloqueia um cartão, a notificação deve ser imediata e multicanal (Push + SMS) para o usuário confirmar a compra.

• Idempotência: Garanta que seu consumer seja idempotente. Receber 2 notificações de "Compra Aprovada" é irritante; receber 2 de "Débito Realizado" gera pânico. Use event_id como chave de deduplicação (Redis é ótimo para isso).

Síncrono vs. Assíncrono: A Diferença Crítica

Veja no componente

acima por que o modelo assíncrono é superior para notificações em escala fintech.

Modelo Síncrono (❌):

• App fica bloqueado esperando resposta
• Se SMS demorar 5s, transação demora 5s+
• Acoplamento perigoso

Modelo Assíncrono (✅):

• App recebe confirmação imediata (202 Accepted)
• Processamento continua em background
• Webhooks notificam status quando disponível

Exemplo de Payload (JSON)

{
  "event_id": "evt_987654321",
  "type": "transaction.pix.received",
  "timestamp": "2026-02-04T14:30:00Z",
  "data": {
    "amount": 150.00,
    "currency": "BRL",
    "sender": "João Silva",
    "user_id": "usr_123"
  },
  "metadata": {
    "priority": "high",
    "fallback_channel": "sms"
  }
}

Conclusão

Desacoplar a lógica de notificação da lógica de negócio é vital para a saúde da sua fintech. Use filas, garanta idempotência e tenha estratégias de fallback claras.

---

Sua arquitetura aguenta a Black Friday? A API da Notifica é nativamente assíncrona e desenhada para alto volume, com webhooks de status em tempo real para alimentar seu Data Lake. Integre com nossa documentação técnica.