Async FastAPI, Medido

Toda a gente diz que async é mais rápido. Finalmente corri os números.

A mesma Books API em Flask e FastAPI como projectos espelho — mesmo Postgres, mesmo schema, mesmas 10k linhas seeded, mesmo host Docker, ambos limitados a 2 CPUs. Flask sob gunicorn 4w/4t. FastAPI sob uvicorn 4w. k6 a gerar carga, 3 workloads, 3 runs cada, mediana reportada.

Workload 1 — read-light (GET livro aleatório de 10k, ramp 50 → 1000 VUs):
1. Flask: 1.476 req/s. FastAPI: 1.692 req/s. Gap ~14%.
2. p50 cliente: Flask 276 ms. FastAPI 165 ms.
3. Veredito: parecido. Escolhe pela ergonomia.

Workload 2 — misto (70% GET / 25% POST / 5% PATCH, ramp 100 → 500 VUs):
1. Flask: 1.326 req/s. FastAPI: 1.413 req/s. Gap ~7%.
2. p50 cliente: Flask 232 ms. FastAPI 171 ms.
3. Veredito: também parecido. A cauda (p95) inclina para Flask sob saturação aqui.

Workload 3 — I/O fanout (cada request faz pg_sleep(50ms), ramp 50 → 500 VUs):
1. Flask: 265 req/s. FastAPI: 992 req/s.
2. p50 cliente: Flask 905 ms. FastAPI 226 ms.
3. **FastAPI = 3,7× o throughput a ¼ do p50 cliente.**

Porque é que o gap do fanout abre tanto:
gunicorn com 4 workers × 4 threads = 16 slots concorrentes. Quando os VUs passam de 16, cada request extra fica em fila numa thread bloqueada à espera do pg_sleep. O event loop do FastAPI segura centenas de coroutines em voo por worker sem bloquear na espera. A diferença do framework aparece exactamente onde a workload passa tempo à espera.

A regra honesta:
1. CRUD de baixa concorrência? Qualquer um dos frameworks serve. O gap de latência está abaixo do ruído.
2. Muitas chamadas I/O lentas concorrentes? Async ganha claramente. WebSockets e streaming vivem aqui também.
3. Trabalho CPU-bound? Nenhum dos dois ajuda. Mete numa worker queue.
4. O custo do async é real — debugging mais difícil, mercado de hiring menor, gotchas de lazy-load. Paga esse custo quando a workload justifica.

Caveat que te devo: isto correu numa máquina de developer, não num cluster cloud. Trata os números como comparação relativa sob condições controladas idênticas, não como capacidade absoluta de produção.

Async em FastAPI é ferramenta, não milagre. Usa onde a workload pede, não porque o README é bonito.

Esta peça fecha a série de 4 partes. Obrigado por ler.

Reprodução completa + dados crus: https://github.com/bilouro/FastAPIProject/tree/main/benchmark

Qual foi a workload que te empurrou finalmente do sync para o async — e o ganho foi mensurável?

P.S. Novo post tech toda a quarta-feira.

#FastAPI #Performance #Python