Alahubs Checkout

• Serviço NestJS isolado da plataforma Alahubs principal, permitindo scaling independente de pagamentos e atualizações sem afetar as operações de usuário.
• Stripe para assinaturas em USD e Mercado Pago para pedidos em BRL unificados em um único endpoint de processamento. Idempotency keys previnem cobrança dupla; cron noturno reconcilia ledgers entre os dois processadores.
• Driver pg nativo com pool de 20 conexões no lugar do Prisma ORM, com 15% de melhoria em latência. Queries parametrizadas, transações atômicas e padrão repository para abstração de dados.
• Alertas em tempo real via webhook Discord para falhas e transações bem-sucedidas. Atribuição de leads com SHA256 de PII enviado à API de Pixel do Meta.

alahubs-checkout-architecture

• Driver pg nativo em vez de Prisma ORM: SQL manual aumenta o custo de manutenção, mas elimina o overhead do ORM e o schema drift. Ganho de 15% em latência para processamento de pagamentos em alto volume.
• Padrão Repository para abstração de dados: Uma camada de indireção extra, mas facilita testes e troca de banco sem tocar na lógica de negócio.
• Endpoint único de pagamento com roteamento interno por provedor: Simplifica a integração com o frontend, mas exige mapeamento cuidadoso de erros: Stripe e Mercado Pago retornam formatos de resposta completamente diferentes.
• Processamento síncrono sem fila de jobs: Endpoint bloqueia até o provedor responder (latência acima de 500ms). Menos complexidade operacional, mas fica refém da lentidão das APIs externas. Bull ou RabbitMQ resolvem isso.

• Stripe usa subscriptions em USD; Mercado Pago usa orders em BRL sem modelo nativo de assinatura. Um enum BillingType e lógica específica por provedor dentro do PaymentsService resolvem o mapeamento. Assinaturas Mercado Pago são emuladas com criação recorrente de pedido e verificações agendadas.
• Queries SQL sem ORM exigem binding manual de parâmetros. Utilitários de query builder com interfaces TypeScript estritas mantêm type safety sem depender do Prisma.
• Uma requisição pode conter vários produtos com descontos diferentes. O repositório de cupons rastreia quais produtos cada cupom se aplica; o cálculo soma as reduções por produto antes de processar o pagamento.
• Meta Ads exige email e nome do usuário para atribuição de lead, mas esses dados não podem ser persistidos em plaintext. Hash SHA256 aplicado no momento da requisição; valores hasheados enviados ao Pixel. PII raw nunca gravado.
• O pool de 20 conexões pode esgotar sob carga. Métricas de pool monitoradas com alertas a 80% de utilização. Requisições não críticas rejeitadas graciosamente quando o pool está próximo do limite.

• Stripe é o processador primário; Mercado Pago é o fallback. Circuit breaker ativa após 3 falhas consecutivas. Reset manual via /admin/circuit-breaker/reset.
• Pool de conexão monitorado via Datadog APM. Alerta se utilização acima de 80% por mais de 5 minutos. Resposta: escalar horizontalmente ou investigar queries lentas.
• Webhooks Discord e Meta Ads disparam de forma assíncrona após transação bem-sucedida. Retentativas com backoff exponencial (1s, 2s, 4s). Falhas persistentes vão para tabela DLQ.
• Cache de produto com TTL de 1 minuto. Invalidação manual via /admin/cache/invalidate?entity=products. Mudanças propagam para réplicas em até 30s.
• Cron noturno às 03:00 UTC compara ledger local com invoices Stripe e pedidos Mercado Pago. Discrepâncias disparam alerta Slack.

• DTOs decorados com class-validator rejeitam requisições malformadas antes de qualquer processamento.
• Todas queries usam parâmetros pg ($1, $2). Nenhuma concatenação dinâmica de SQL permitida.
• Cupons identificados por slug, sem IDs inteiros sequenciais. Previne força bruta. Criação limitada a endpoints admin com guards de role.
• Chave secreta Stripe nunca hardcoded ou logada. Rotação trimestral via gerenciador de segredos no CI/CD.
• Todos os webhooks Stripe validados via header sig_* antes de qualquer processamento.

• Trocar processamento síncrono por filas com Bull ou RabbitMQ. O endpoint retornaria imediatamente; workers processariam a transação em background.
• Retries automáticos com backoff exponencial para falhas transitórias de rede sem intervenção manual.
• Ledger de transações imutável para trilha de auditoria completa e resolução de disputas sem depender das APIs de terceiros.
• Portal de autoatendimento para clientes gerenciarem faturas, métodos de pagamento e tiers de assinatura.