Uma sessão por requisição
As duas tarefas usam transações e conexões independentes. Nenhum AsyncSession é compartilhado.
DADOS FICTÍCIOS · EXECUÇÃO GRAVADA
Duas compras.
Uma última unidade.
A API precisa acertar quando as requisições chegam juntas. Veja o PostgreSQL serializar a disputa e manter venda, estoque e auditoria consistentes.
Esta página é uma demonstração gravada, não uma API hospedada. Os dados vêm de requisições HTTPX/ASGI à aplicação FastAPI usando conexões reais ao PostgreSQL. A animação apresenta a evidência capturada, não é uma gravação de tela. Nenhum cadastro ou dado real é utilizado.
OPENTELEMETRY / EXECUÇÃO CAPTURADA
Do endpoint à transação.
| Span | Duração | Linha do tempo |
|---|
A espera inclui o bloqueio controlado criado pelo teste. Estes tempos comprovam a sequência; não são um benchmark de latência. Somente o request_id correlaciona a execução; as métricas de negócio não têm labels de tenant, cliente ou usuário.
Por que funciona
Bloqueio na linha
SELECT FOR UPDATE faz a segunda compra ler o saldo atualizado depois do commit da primeira. Itens são bloqueados em ordem de UUID.
Tudo ou nada
Venda, itens, saldo e movimentação fazem parte do mesmo commit. A tentativa sem estoque faz rollback sem deixar registros parciais.
Transcrição acessível do vídeo
Há uma unidade no estoque e duas compras chegam juntas. Cada compra usa sua própria sessão e transação. O teste segura a linha por alguns instantes, confirma duas conexões em espera no PostgreSQL e libera a barreira. Uma compra desconta a unidade, confirma a transação e recebe HTTP 201. A outra retoma, lê o saldo zero, recebe HTTP 422 e desfaz a transação sem gravar uma segunda venda. Um identificador conecta endpoint, autenticação, permissão, bloqueio e transação. Resultado: uma venda, estoque zero e nenhuma duplicidade.