Pular para o conteúdo

ZapFlowBR | Plataforma WhatsApp-First de Comercio Multi-Tenant

Plataforma SaaS multi-tenant de atendimento e venda via WhatsApp, com ticketing, chatflows configurados por tenant e gestão de contas WhatsApp Business, em produção com clientes pagantes.

Construida é operada por um time de engenharia de 1 pessoa, do zero a produção.

Contexto e Problema Real

O WhatsApp é o canal dominante no Brasil. Para pequenas e medias empresas, uma plataforma multi-canal profissional tem custo mensal prohibitivo é onboarding complexo. A oportunidade era construir uma solução onde o cliente ja estava, com custo compativel e configuração que o próprio dono operasse. O mercado tinha solucoes sofisticadas para grandes e ferramentas basicas para micro-empresas. O meio estava vazio.

Meu Papel

Sou o arquiteto e engenheiro principal. Projetei a estrutura multi-tenant, integrei as conexoes de WhatsApp, defini o modelo de dados de ticketing, configurei o Docker de produção é opero os deploys. Não tenho co-fundador técnico: nenhuma outra pessoa tomou decisão de sistema neste produto.

As Decisões que Importaram

Decisão 1: Node.js com TypeScript e Sequelize em vez de alternativas mais modernas.

Quando defini a stack, havia opções mais modernas: Bun em vez de Node, Prisma em vez de Sequelize, edge em vez de servidor tradicional. Escolhi a stack estabelecida porque a base existente tinha maturidade para produção sem reescrita, é cada hora de reescrita era uma hora sem entrega para cliente pagante. A decisão foi aceitar divida técnica controlada em vez de reescrita sem retorno imediato. O custo da divida é previsível. Uma reescrita sem cliente garantido não e.

Decisão 2: Docker Compose em vez de Kubernetes para produção.

Com um time de engenharia de 1 pessoa, Kubernetes adicionaria overhead operacional que eu não teria como absorver: troubleshooting de pods, networking de cluster, certificacoes de seguranca de infraestrutura. Docker Compose com serviços nomeados é suficiente para o volume atual de clientes, tem zero overhead de aprendizado para quem eventualmente herdar a operação, é o rollback de qualquer serviço e quatro comandos. O custo dessa decisão é a limitacao de escala horizontal automática: não consigo escalar um serviço específico sem escalar o host inteiro. E uma decisão consciente: otimizei para operabilidade de 1 pessoa, não para escala hipotetica sem cliente correspondente.

Decisão 3: reconexao de contas WhatsApp em batch sequencial, não paralelo.

Quando o backend reinicia, ele precisa reconectar todas as contas WhatsApp Business ativas dos tenants. A implementação inicial reconectava tudo em paralelo. O resultado foi rate limiting do serviço de WhatsApp e falhas de autenticacao em cascata: uma conta mal reconectada bloqueava as seguintes. Mudei para reconexao sequencial com as contas principais primeiro e pools de backup depois, com janela de estabilizacao de aproximadamente 2 minutos pós-boot. Custa tempo de indisponibilidade na reinicializacao do backend, mas elimina completamente as falhas de autenticacao em cascata que eram impossíveis de diagnosticar em paralelo porque o estado de cada conta interferia no das outras.

Decisão 4: imagens Docker versionadas por data e número de versão para rollback rápido.

Cada build gera uma imagem com tag no formato data+versão. O docker-compose.prod.yml aponta para a tag exata, nunca para “latest”. Rollback de um deploy problemativo e editar uma linha e restartar. Foi decisão explicita contra a conveniencia de “latest”: sem tag fixa, rollback exige rebuild ou registro manual de qual imagem estava antes. Com tag fixa, 30 segundos.

O que Deu Errado

O frontend foi construido em Vue 2 com Quasar Framework. Vue 2 entrou em End of Life em dezembro de 2023. A migracao para Vue 3 é um projeto de escopo consideravel que ainda não aconteceu, porque o custo de migracao não se justifica sem um trigger de negocio claro. O resultado prático é que cada dependencia de frontend que atualiza precisa ser avaliada contra compatibilidade com Vue 2, é algumas funcionalidades modernas do ecossistema ficam inacessiveis. Foi uma decisão tecnicamente correta no momento em que foi tomada. Hoje é o maior ponto de divida técnica do produto, e eu a carrego conscientemente até o momento certo de migrar.

Resultado e Evidencia

Plataforma em produção com clientes ativos gerenciando contas reais de WhatsApp Business. O sistema opera ticketing, chatflows por tenant e integração com canais externos. Rollback disponivel em menos de 1 minuto.

Stack

  • Backend: Node.js, TypeScript, Sequelize, PostgreSQL
  • Frontend: Vue 2, Quasar Framework
  • Infra: Docker Compose em VPS dedicada, imagens versionadas por data e versão
  • Integração WhatsApp: wbot
  • Autenticacao: JWT com RBAC por tenant