Plataforma de estudos com pagamento, acesso e provas cronometradas

+-------------+  +-------------+  +------------------------+
| site de     |  | aplicação   |  | painel de operação     |
| venda       |  | do aluno    |  | com 2FA obrigatório    |
+------+------+  +------+------+  +-----------+------------+
       |                |                     |
       +----------------+---------------------+
                        | Server Actions
                        v
+----------------------------------------------------------+
| pacotes compartilhados, no servidor: preço, acesso,      |
| cobrança, segurança, geração de questões e fiscal        |
+------+--------------------+---------------------+--------+
       |                    ^                     |
       v                    | webhook assinado    v
+-------------+  +----------+---------+  +-----------------+
| PostgreSQL  |  | checkout hospedado |  | modelo de       |
| com RLS     |  | no provedor de     |  | linguagem com   |
|             |  | pagamento          |  | saída validada  |
+-------------+  +--------------------+  +--------+--------+
                                                  v
                              +-------------------+--------+
                              | questão nasce inativa até  |
                              | a revisão humana           |
                              +----------------------------+

Contexto e problema

Quem estuda para concurso compra material genérico e não sabe se está pronto para aquela prova. O produto vende acesso por concurso e aplica provas cronometradas comparáveis entre alunos. Para isso precisa cobrar sem confiar no navegador, liberar e revogar acesso sem erro de dinheiro e usar IA para produzir questões sem publicar nada que uma pessoa não tenha revisado.

Arquitetura

Monorepo com três apps Next.js (site de venda e conteúdo, aplicação do aluno, painel de operação) e pacotes compartilhados. As regras críticas, como preço, acesso, cobrança, segurança, geração de conteúdo e fiscal, ficam nos pacotes, e as três telas usam exatamente a mesma lógica.

• Dados: PostgreSQL com migrações versionadas. Tabelas sensíveis novas nascem com RLS e com os privilégios dos papéis anônimos revogados.
• Identidade: instâncias de autenticação separadas para aluno e admin, com segredos e cookies distintos, bloqueio por tentativas e 2FA obrigatório no admin.
• Dinheiro: preço calculado no servidor, checkout hospedado no provedor, webhook assinado e idempotente, estorno e chargeback revogando o acesso na mesma transação.
• Prova cronometrada: cronômetro, sorteio e correção no servidor, com trava transacional para que duas provas simultâneas não gerem dois créditos de ranking.
• Geração de questões e leitura de provas: geração de questões e extração de provas em PDF com saída estruturada revalidada por schema; o texto do PDF é tratado como dado não confiável; custo máximo reservado antes de cada chamada.
• Jobs: rotinas idempotentes para LGPD, campanhas em lotes e fila fiscal com lease, cada uma com batimento para alerta por ausência.

Desafios

• Documentação otimista. A documentação dizia que as nove regras de negócio críticas estavam íntegras. Uma auditoria linha a linha mostrou que só duas estavam sem ressalva. Os quatro furos de dinheiro e acesso foram corrigidos em seis dias, com um ADR para cada.
• CI verde que validava pouco. O type-check não rodava nos apps e a suíte e2e não executava nada. Em paralelo, o compilador estourava a pilha num tipo gerado pelo ORM e escondia 45 erros; a causa foi isolada testando variantes uma a uma.
• Latência que nenhum código resolveria. A medição apontou a distância entre função e banco, e não as consultas.
• Oferta sem entrega. O checkout aceitava um item sem material publicado. A solução foi um predicado único de “oferta entregável”, usado pela publicação, pelo checkout e pelo catálogo.

Solução

As regras de dinheiro, acesso e dados pessoais saíram das telas e foram para pacotes testados contra Postgres real. Cada uma virou invariante com dono, teste e um portão de revisão obrigatório que pode bloquear a mudança. Quando a falha era de concorrência, a correção usou a primitiva do banco (operação condicional, trava transacional, releitura dentro da transação) em vez de lock externo. A entrega passou a ser controlada pelo CI e por um portão local que exige os checks no commit exato e uma revisão separada da implementação.

O que eu faria diferente

Escreveria os testes de concorrência antes das telas, e não depois da auditoria. E trataria desde o primeiro dia a documentação de estado como algo que precisa de prova e data: foi ela que escondeu os furos por mais tempo.