CreatorOps

O fluxo cobre programa, creator, cupom ou link, venda, comissão e pagamento. As regras de negócio vêm antes da tecnologia: cupom válido vence clique, atribuição confirmada não é reescrita em silêncio, evento atrasado não faz um pedido voltar de estado, dinheiro nunca é float e o ledger só recebe lançamentos novos. Uma devolução depois do pagamento reduz o saldo disponível, pode deixá-lo negativo e nunca desfaz em silêncio uma transferência já confirmada.

É um monólito modular com nove limites: identidade, programas, parcerias, atribuição, comissões, escuta de conteúdo, financeiro, controle agêntico e relatórios. A escolha é deliberada, porque o objetivo é estudar regras transacionais, e cada limite pode virar um serviço quando volume, equipe ou isolamento justificarem.

Quem muda uma decisão ou dinheiro abre uma transação no serviço. Locks (SELECT … FOR UPDATE), chaves únicas e índices parciais protegem as invariantes sob concorrência, e o evento de domínio entra na outbox na mesma transação. A publicação é at-least-once, e cada consumidor registra a inbox antes de aceitar qualquer efeito.

O ledger trabalha em pares de lançamentos por bucket: a comissão nasce pendente, é liquidada para disponível, reservada no lote de pagamento e confirmada como paga, ou volta a disponível se a transferência falhar.

O caso difícil é o payout ambíguo. Se o provedor processa a transferência e a resposta se perde por timeout, o pagamento fica como desconhecido e a reserva permanece: a falta de resposta não prova que falhou. O sistema nunca cria uma segunda chave de idempotência; consulta o provedor pela chave original. A correção passa por um achado imutável com evidência e hash, uma proposta sem efeito colateral, gates determinísticos e aprovação do financeiro com comentário. O executor repete os gates dentro da transação, e se a versão mudou a proposta vira obsoleta.

Segurança: HMAC sobre o corpo bruto do webhook, com comparação em tempo constante; o JWT da equipe carrega a marca ativa, mas cada requisição confirma o vínculo no banco; os serviços filtram pela marca antes de carregar ou bloquear qualquer recurso; os erros seguem o formato Problem Details, sem stack trace nem pista da existência de dados de outra marca. A configuração local falha se os endereços dos emuladores estiverem ausentes, para nunca cair por acidente na nuvem real.

Um provedor financeiro simulado falha de propósito, para provar o caminho do erro. Logs estruturados, métricas no Prometheus e traces no Jaeger.

Stack completa: FastAPI, Pydantic v2, SQLAlchemy 2 assíncrono, PostgreSQL 16, Alembic, Pub/Sub e Firestore em emulador. Verificação com Ruff, mypy estrito e testes contra Postgres real.