Alahubs

• 8+ domínios de funcionalidades interconectados abrangendo métricas de saúde (rastreamento biométrico, sono, esportes), lifestyle (hábitos, metas, planejamento de refeições), crescimento intelectual (notas de leitura, armazenamento criptografado) e 40+ modelos PostgreSQL modelando relações complexas de usuários e tiers de assinatura.
• Inference engine em tempo real via Socket.IO + Redis pub/sub em deploy multi-instância, 5 workers dedicados (notificações, geração de refeições, processamento de filas, recuperação) e OpenAI Assistant API com function calling para geração inteligente de refeições com breakdown nutricional.
• Camada de pagamentos dual-processor (Stripe + Mercado Pago) com gestão automática de assinaturas, Meta Ads conversion tracking com browser fingerprint + UTM, funil de captura de leads com otimização de CAC de 15-30% e idempotency keys para confiabilidade de settlement.
• PWA + arquitetura offline-first com Service Worker (acesso a sistema de arquivos, message ports), encriptação de campo para dados biométricos/sensíveis e pipeline de analytics rastreando adoção de features, engajamento e métricas de monetização em 6 libs de visualização (D3, ApexCharts, Recharts, Google Charts, Cytoscape).

alahubs-architecture

• Separação em microserviços: plataforma principal + serviço de checkout dedicado: Aumenta a complexidade de deploy, mas desacopla o scaling de pagamentos das operações de usuário; permite migração independente de Stripe/Mercado Pago ou evolução de features.
• OpenAI Assistant API ao invés de endpoints de completion para geração de refeições: Latência um pouco maior (1-3s) vs completions brutas, mas contexto thread-based persistente permite conversas multi-turn e function calling para cálculos nutricionais sem prompt engineering.
• Redis pub/sub para real-time + padrão de worker queue ao invés de event sourcing: Mais simples que event sourcing completo, mas exige idempotência cuidadosa; polling de 30s para geração de refeições ao invés de triggers event-driven para evitar thundering herd.
• Workers Node.js junto do servidor NestJS (node-cron) ao invés de sistema de job queue separado: Acoplamento maior, mas menor overhead operacional; cada deploy inclui todos os workers, sem necessidade de fleet de workers separada.

• Coordenação multi-instância em tempo real: Socket.IO com adapter Redis exige sincronização pub/sub entre instâncias. Resolvido com @socket.io/redis-adapter 8.3.0 e event broadcasting padronizado; updates de feed de atividades, conclusões de hábitos e progresso de geração de refeições transmitidos via única instância Redis para todos os clientes conectados. Latência <200ms alcançada via connection pooling.
• Geração de refeições com OpenAI sujeita a restrições nutricionais: Assistant API não suporta diretamente typed function returns. Resolvido definindo schemas estruturados em definições de funções (macros: carboidratos/proteínas/gorduras, micronutrientes: vitaminas A/C, cálcio/ferro), parseando respostas tool_call JSON com validação, e enfileirando geração multi-step (refeição base → análise nutricional → geração de imagem) com acompanhamento de status MealGenerationQueue.
• Reconciliação dual payment processor: Stripe cobra em USD, Mercado Pago em BRL; modelos de assinatura diferentes (Stripe: subscriptions, Mercado Pago: orders). Resolvido com camada de abstração em checkout service mapeando ambos para modelo interno SubscriptionPayments com enum provider (STRIPE | MERCADO_PAGO); idempotency keys previnem dopla cobrança em retry.
• Encriptação de campo para dados biométricos: User.encryptionKey + IV armazenados criptografados; chave de decriptação apenas em memória de runtime. Resolvido com bcrypt para hash de master key, AES-256 para encriptação de campo, e constraints de nível de BD prevenindo armazenamento em plaintext.
• Atribuição de leads entre plataformas de Ads: Meta fbp/fbc tokens expiram; parâmetros UTM perdem-se em redirects. Resolvido com browser fingerprint (FingerprintJS) persistido em localStorage, Redux state e modelo Leads; captura fbp, fbc, GCLID, TTCLID, utm_source/campaign no signup para reconstruir cadeia completa de atribuição para pixel conversion tracking.

• Scaling de BD: Migrations Prisma com shadow database previnem drift. Instância Pg monitorada via CloudWatch; índices em [userId, habitId, date] para registros de hábitos, [senderId, receiverId] para amizades otimizam queries read-heavy. Backup: snapshots automatizados diários para S3.
• Redis failover: Session + adapter Socket.IO replicam para instância backup. Se primary cai, app mantém degradação graciosa de 30s (mensagens enfileiradas em buffer); failover manual dispara promoção redis-cli SLAVEOF.
• Recuperação de crash de worker: Cada worker monitorado via Docker health checks. Em falha, Kubernetes reinicia container; jobs inacabados (status=processing) detectados por stucked-processing worker (roda a cada 5min), transicionados de volta para pending e re-enfileirados.
• Reconciliação de pagamentos: Cron noturno compara ledger de invoices Stripe vs SubscriptionPayments local; pedidos Mercado Pago buscados via API polling. Discrepâncias disparam alerta Slack para investigação manual. MRR calculado de assinaturas ativas com análise de tendência histórica.
• Monitoramento de quota OpenAI: Uso de endpoint rastreado em FeaturesUseRecords; alertas de soft limit em 80% de gasto mensal. Degradação graciosa: se quota excedida, geração de refeição enfileirada com notificação do usuário ("Em breve"). Aumento manual de quota coordenado com billing.

• Encriptação de campo: User.encryptionKey (AES-256 envolvido em bcrypt) + IV armazenados em BD; dados biométricos em plaintext nunca são escritos. Decriptação acontece em-memória pós-retrieval.
• JWT + guards baseados em role: Access tokens curta vida (15min); refresh tokens rotacionados no uso. Route guards checam decorator @Auth(); roles (user, admin, moderator) avaliados via reflectors.
• Tokens de reset de senha: Geração aleatória segura, TTL 1 hora, single-use (marcado com used=true). Rate limiting via ThrottlerModule (5 requisições/hora por IP).
• Dados de pagamento: Stripe/Mercado Pago lidam com compliance PCI; app nunca armazena números de cartão completos. Entidade CustomerCard armazena apenas token + últimos 4 dígitos para exibição.
• CORS + CSRF: Frontend deployed em domínio separado; conexões Socket.IO validadas via JWT middleware. URLs CloudFront assinadas previnem acesso não autorizado a S3.

• Async job queue library: Substituir node-cron + workers customizados por Bull ou RabbitMQ para melhor observabilidade, retries e scaling.
• GraphQL API layer: Endpoints REST atuais poderiam se beneficiar de batching (Geração de Refeição + Conclusão de Hábito em única requisição).
• Event sourcing + CQRS: Trilha de auditoria para todas as ações de usuário; habilita queries temporais ("mostre meus stats de 3 meses atrás").
• Recomendações de hábitos dirigidas por ML: Prever quais hábitos o usuário deve começar baseado em clustering comportamental + similarity de OpenAI embedding.
• Geração de vídeo: Vídeos de prep de refeição + tutorials de workout com narração de IA (Synthesize speech) para aumentar engajamento e retenção.