Sistemas que construí

Detalhe técnico: a tabela-fato consolida ~106 mil pedidos com sync incremental a cada 15 minutos, integrando 7 fontes de dados — Shopify Admin API (REST + GraphQL), Meta Marketing API, GA4 Data API, Tiny ERP de 3 empresas diferentes, UpPromote (afiliados), Stamped.io (reviews) e Google Sheets (metas). A atribuição multi-touch é motor próprio, reconstruído a partir da jornada do cliente (last-click não-direto) — não a API pronta de nenhuma plataforma. PII fica cifrada em repouso com AES-256-GCM, e um HMAC-SHA256 permite contar clientes únicos sem nunca expor o dado em claro. O motor de margem/custo por canal é configurável, então o lucro real considera custo de produto e taxa por canal, não só receita bruta.

Detalhe técnico: a atribuição casa venda↔campanha por utm_term=campaign.id — identificador imutável que sobrevive a renomear a campanha — com 4 camadas de fallback caso o parâmetro falhe. Além das travas de sROAS, o autopilot respeita um teto agregado de conta, não mexe em campanha que ainda está na trava de aprendizado do Meta, aplica cooldown de aumento (no máximo 1x a cada N dias por campanha) e limita a variação máxima por rodada para evitar oscilação. O estado persiste cifrado em AES-256-GCM, a chamada à Graph API tem retry com backoff e respeito ao header Retry-After, e um dead-man's switch (heartbeat + healthcheck + alerta no Telegram) avisa se o robô parar de rodar. Roda via supercronic, está na versão 3, com testes unitários e deploy programático.

Detalhe técnico: os três sinais — co-compra, semântico e popularidade — entram normalizados por rank antes de somar, para que uma escala diferente entre eles não domine o resultado sozinha. A intenção complemento/substituto decide se a sugestão empurra "leva junto" ou "alternativa"; a diversidade por família de produto evita mostrar 5 variações do mesmo item; a penalidade de preço evita empurrar sempre o mais caro do catálogo. A flag de rollback existe porque motor de recomendação é o tipo de sistema que erra silencioso — dá para reverter pro sinal anterior sem redeploy.

Detalhe técnico: o guard não se contenta com e-mail — cruza contato, e-mail, telefone e ID da loja (Shopify) antes de disparar qualquer lembrete ou cupom. O último campo importa porque a mesma automação atende mais de uma loja: sem o ID da loja no cruzamento, um cliente que já comprou na loja A poderia receber cupom disparado pela loja B só por coincidência de e-mail ou telefone. Foi exatamente essa lacuna — checagem por um campo só — que causou o bug original.

Detalhe técnico: a Conversions API deduplica eventos por event_id — evita contar a mesma venda duas vezes quando o pixel do navegador e o servidor mandam o mesmo evento — e faz hashing de PII antes de enviar, o que sobe o EMQ (Event Match Quality), a nota que o Meta dá pra qualidade do sinal recebido. O conector que injeta gasto do Meta Graph e do GA4 de volta na Shopify é idempotente (pode rodar de novo sem duplicar linha) e roda em cron diário, mantendo o cálculo de ROAS real sempre com o gasto do dia certo.

Detalhe técnico: cada tenant nasce de uma imagem base comum e recebe patches versionados por cima — rebrand por tag fixa, não fork de código, então uma correção sobe para todas as lojas de uma vez. A automação (que mensagem, quando, pra quem) é resolvida por override gravado em banco por tenant, não por deploy separado — mudar um fluxo de uma loja não exige subir código novo. O cupom é emitido via integração OAuth própria com a Shopify de cada loja, e webhooks de pedido/cliente acionam os fluxos em tempo real.

Detalhe técnico: a emissão passou por três blindagens depois de incidentes reais de produção. Primeiro, a fila sofria head-of-line blocking — pedidos de pré-venda, por serem os mais antigos, ocupavam todas as vagas do ciclo e travavam os pedidos normais; corrigido com um ORDER BY que prioriza o pendente e só encaixa pré-venda se sobrar vaga. Depois, um ECONNRESET no sync abortava o ciclo inteiro e não faturava nada: agora cada etapa tem retry com backoff (respeitando 429/Retry-After) e try/catch isolado, então a emissão sempre acontece mesmo se o sync falhar. Por fim, a busca de pedidos no ERP lia só a primeira página (100 pedidos): em pico, tudo além do 100º ficava invisível — corrigido com paginação completa e teto configurável. O serviço reavalia a cada tick, e um pedido de pré-venda vira nota sozinho no instante em que o estoque fica positivo.

Detalhe técnico: o coração da regra é um carimbo de data (metafield por variante) que resolve um problema sutil — ao ligar a pré-venda de um tamanho que acabou de zerar, pedidos antigos comprados com estoque físico seriam etiquetados e segurados por engano; a nota fiscal só segura o pedido cuja data é posterior ao carimbo. O mesmo carimbo é lido pelo serviço de faturamento, então os dois sistemas concordam sobre o que é pré-venda sem duplicar lógica. Há ainda o cuidado com o desconto automático da Shopify, que não aceita ficar sem itens: a solução foi um produto-âncora em rascunho (não comprável) fixo no desconto, para nunca vazar o desconto nos tamanhos que ainda têm estoque. Quando o lote chega, o tamanho volta a "esgotado até repor" e sai do desconto sozinho.

Detalhe técnico: antes de gerar a resposta, o serviço faz uma busca semântica (RAG com Qdrant + embeddings bge-m3) na base de conhecimento e no catálogo da loja, com piso de score — se nada relevante volta, ele responde mesmo assim, mas sem contexto inventado (fail-open com timeout, nunca trava o atendimento). A geração usa uma cadeia de 3 provedores em ordem de custo (um modelo econômico primeiro, dois de reserva pagos e grátis), devolvendo a primeira que responder — resiliência sem depender de uma única API. O system prompt é mantido com prefixo estável e cacheável pra baratear cada chamada, e o painel de revisão tem autenticação com hash bcrypt. Roda em produção na versão 1.7.

Detalhe técnico: o serviço lê o estoque pela Shopify Admin API e cruza o retorno de cada variante específica (tamanho, não produto) com a lista de quem pediu aviso — o cliente que queria o 38 não é notificado quando volta o 42. O registro do interesse é feito por tag no ActiveCampaign, o que deixa o disparo do aviso rodar dentro do próprio fluxo de e-mail marketing da loja, sem construir uma régua de envio paralela. É a mesma demanda que a pré-venda ataca pela frente: um evita perder a venda antes do produto chegar, o outro recupera a venda depois que ele esgota.