Plataforma SaaS de assistentes de IA conversacional operada entre julho de 2022 e dezembro de 2024, cobrindo 7 segmentos de tenant com billing recorrente e atendimento multi-canal.
01. Fintech
Dai Tec AI
Plataforma SaaS de assistentes de IA conversacional multi-tenant, com billing recorrente em Stripe e atendimento em WhatsApp. Deploy caiu de 40 para 8 minutos.
Node.js / TypeScript AWS Stripe
-80% TEMPO DE DEPLOY / 40MIN -> 8MIN
-
01 Contexto
A DAI-TEC operava um SaaS de assistentes de IA conversacional atendendo 7 segmentos de tenant, com entrada por WhatsApp e cobrança recorrente. Cada deploy levava 40 minutos e precisava ser repetido em 3 ambientes, o que travava a frequência de entrega. Do lado do produto, cada segmento novo exigia isolamento de consumo e de cobrança sem duplicar a base de código.
-
02 Ação
Estruturei a camada de CI/CD com GitHub Actions, Docker e AWS (ECR/ECS) cobrindo os 3 ambientes. No produto, implementei o billing recorrente com Stripe -- checkout, webhooks, assinaturas, invoices, cartão e boleto -- e operei o backend Node.js/TypeScript sobre MongoDB sustentando os 7 segmentos de tenant com isolamento de consumo. A camada conversacional integrou 4 provedores de WhatsApp e 29 workflows n8n para orquestração de canal, sobre uma stack de IA com RAG em Qdrant, LiteLLM e 6 agentes especializados. Observabilidade via Prometheus, Grafana e Loki.
-
03 Resultado
Deploy de 40 para 8 minutos (-80%), com mais de 737 execuções de pipeline acumuladas nos 3 ambientes. Os 7 segmentos de tenant passaram a rodar em produção com cobrança recorrente e isolamento de consumo, e a troca de provedor de WhatsApp deixou de ser mudança de código.
-
04 Aprendizado
Billing é o subsistema que menos perdoa: webhook do Stripe chega fora de ordem e pode repetir, então idempotência por evento precisa existir desde o primeiro dia, não depois do primeiro incidente de cobrança duplicada. E abstrair os 4 provedores de WhatsApp atrás de uma interface custou tempo antes de pagar -- só virou vantagem clara quando um provedor degradou e a troca foi configuração em vez de refactor.
Arquitetura
Cada componente carrega a decisão que foi tomada ali e o que ela custou.
Arraste para explorar o diagrama.
entradaserviçodadosexternoassíncrono
Clique em um componente para ver a decisão tomada ali e o que ela custou.
Ver todas as decisões em texto
- Integrar 4 provedores de WhatsApp atrás de uma interface única, em vez de acoplar o backend ao SDK de um só.
- Trade-off: Custou uma camada de adaptação a mais e trabalho adiantado que não gerava feature visível. Pagou quando um provedor degradou: a troca virou configuração, não refactor.
- n8n
- Orquestrar canal e integrações em 29 workflows n8n, mantendo fora do backend a lógica que mudava por cliente.
- Trade-off: Parte do comportamento do sistema passou a viver fora do controle de versão do backend, o que dificulta review e testes. Em troca, ajuste de fluxo por cliente parou de exigir deploy.
- API Node.js / TS
- Backend único multi-tenant com isolamento de consumo por segmento, em vez de uma instância por cliente.
- Trade-off: Todo caminho de dados precisa carregar o tenant corretamente -- um vazamento entre tenants seria falha grave. Evitou multiplicar operação e custo por 7.
- Stripe
- Delegar cobrança recorrente ao Stripe (assinaturas, invoices, cartão e boleto) em vez de construir controle de cobrança próprio.
- Trade-off: Amarra o modelo de cobrança ao vocabulário do Stripe e a uma taxa por transação. Em troca, PCI, retentativa de cobrança e emissão de invoice deixaram de ser código nosso.
- LiteLLM + 6 agentes
- Colocar o LiteLLM como camada única de acesso a modelo, com 6 agentes especializados em vez de um agente genérico.
- Trade-off: Mais superfície para manter e roteamento a decidir. Em compensação, trocar de modelo virou configuração, e agente com escopo estreito erra menos que um que tenta fazer tudo.