Arquitetura do LIP
O LIP utiliza uma arquitetura híbrida inovadora combinando dois bancos de dados para otimizar performance e custo:
- Firebase Firestore: Dados em tempo real (conversas, mensagens)
- PostgreSQL (Supabase): Dados estruturados (CRM, analytics)
Visão Geral da Arquitetura
┌─────────────────────────────────┐
│ WhatsApp Users │
│ (Clientes finais) │
└─────────────────────────────────┘
│ │ │
│ │ │ Mensagens
↓ ↓ ↓
┌─────────────────────────────────┐
│ WhatsApp Business API │
│ (Meta Cloud API) │
└─────────────────────────────────┘
│
│ Webhooks
↓
┌─────────────────────────────────┐
│ LIP Backend │
│ (Node.js + Express + IA) │
│ │
│ • Webhook Handler │
│ • OpenAI Integration │
│ • Flow Engine │
│ • CRM Logic │
│ • Multi-tenant Auth │
└─────────────────────────────────┘
│ │
│ │
┌──────┼────────────┼──────┐
│ │ │ │
↓ ↓ ↓ ↓
┌─────────────┐ ┌─────────────┐
│ Firebase │ │ PostgreSQL │
│ Firestore │ │ (Supabase) │
│ │ │ │
│ • Conversas │ │ • CRM │
│ • Mensagens │ │ • Analytics │
│ • Agentes │ │ • Relatórios│
│ • Configs │ │ • Deals │
└─────────────┘ └─────────────┘
│ │
│ Real-time │ REST API
│ │
↓ ↓
┌─────────────────────────────────┐
│ LIP Frontend │
│ (Next.js 15 + Redux) │
│ │
│ • Dashboard │
│ • Chat Interface │
│ • Flow Builder │
│ • CRM │
│ • Analytics │
└─────────────────────────────────┘
│
↓
┌─────────────────────────────────┐
│ Agentes/Usuários │
│ (Dashboard interno) │
└─────────────────────────────────┘
Banco de Dados Híbrido
Por que híbrido?
| Característica | Firebase Firestore | PostgreSQL |
|---|---|---|
| Velocidade | ⚡⚡⚡ Instantâneo | ⚡⚡ Rápido |
| Tempo Real | ✅ Nativo | ❌ Polling |
| Queries Complexas | ❌ Limitado | ✅ Full SQL |
| Custo | 💰 Por uso | 💰💰 Fixo |
| Analytics | ❌ Básico | ✅ Avançado |
Decisão:
- Firestore: Conversas e mensagens (100% tempo real)
- PostgreSQL: CRM e analytics (queries complexas, relatórios)
Componentes Principais
1. WhatsApp Integration
Webhook handler para processar mensagens:
2. OpenAI Integration
Chatbot inteligente:
3. Multi-Tenant Auth
Firebase Auth com custom claims:
Padrões de Design
1. Repository Pattern
Camada de dados com Prisma:
2. Factory Pattern
Criação de objetos complexos:
3. Observer Pattern
Eventos e notificações:
Escalabilidade
Horizontal Scaling
O LIP suporta escalabilidade horizontal através de:
- Load Balancing: Distribuição de carga entre instâncias
- Stateless Services: Serviços sem estado persistente
- Shared Cache: Cache compartilhado via Redis
- Database Replication: Réplicas de leitura do banco
Vertical Scaling
Otimizações para máximo desempenho:
- Connection Pooling: Pool de conexões do banco
- Memory Caching: Cache em memória para dados frequentes
- Worker Threads: Processamento paralelo
- Query Optimization: Consultas otimizadas
Segurança
Autenticação
Autorização
Criptografia
Monitoramento
Logs Estruturados
Métricas
Health Checks
Deployment
Container Architecture
Kubernetes
Performance
Benchmarks
| Operação | Requisições/s | Latência Média | P95 | P99 |
|---|---|---|---|---|
| GET /api/users | 10,000 | 15ms | 25ms | 45ms |
| POST /api/users | 5,000 | 30ms | 50ms | 80ms |
| GET /api/search | 8,000 | 20ms | 35ms | 60ms |
Otimizações
- Database Indexing: Índices estratégicos nas tabelas
- Query Caching: Cache de consultas frequentes
- CDN Integration: Distribuição de assets estáticos
- Compression: Compressão gzip/brotli
- Lazy Loading: Carregamento sob demanda
Próximos Passos
- Componentes - Conheça os componentes em detalhes
- API - Documentação completa da API
- Deploy - Guia de deployment
Última atualização
26 de novembro de 2025