Produto de dados · Em produção
World Cup Analytics
Produto analítico para explorar dados da Copa do Mundo 2026: partidas, seleções, jogadores, xG, mapas de chute e estatísticas da competição.
01
Contexto
O World Cup Analytics é uma leitura analítica da Copa do Mundo 2026 — partidas, seleções e jogadores explicados com dados. Está no ar em worldcup.jvmello.dev, com a base se atualizando sozinha durante a competição.
02
Problema
Dados brutos de partida (eventos, escalações, estatísticas) não contam uma história por si só, e servir agregações complexas em tempo de request não escala: com a competição avançando, uma chamada de API chegou a varrer centenas de arquivos e levar segundos para responder.
03
Objetivo
Construir um produto: fundo escuro, tipografia forte e regras duras de apresentação. Percentil nunca como manchete, taxas sempre por 90 minutos, confrontos indefinidos sem ID interno, com o dado servido pronto, nunca agregado na hora.
04
Arquitetura
Um único container FastAPI serve a SPA e a API. Os dados percorrem duas camadas: bronze (JSON bruto da fonte, em disco) e gold (payloads pré-computados em PostgreSQL). A infraestrutura possui Caddy com TLS automático atrás do Cloudflare, Postgres em rede interna, backups diários, tudo vivendo em um repositório separado.
05
Dados
A fonte é a TheStatsAPI: cada partida vira um bundle de sete endpoints (escalações, estatísticas de jogadores, timeline de eventos, mapa de chutes, árbitro...). A ingestão é idempotente por endpoint, respeitando um limite de ~12 requisições/minuto. Retomar uma ingestão interrompida custa segundos, não horas.
06
Pipeline
Um builder lê o bronze uma única vez e grava tudo via staging + swap em uma transação: se falhar no meio, o build anterior continua servindo. A tabela api_payloads guarda o JSON exato que cada endpoint responde. Mais de 8.500 payloads pré-computados, incluindo perfis de jogador por edição, fase e partida.
07
API
Com o payload pronto em disco, o handler do FastAPI vira um SELECT de uma linha. Endpoints que levavam segundos para responder passaram a levar 30–40 ms.
08
Frontend
SPA em JavaScript puro, sem framework, com identidade visual própria da Copa. Os textos analíticos, contextos de destaque do jogador, diagnóstico de seleção, leituras de confronto vêm de um motor de regras sobre percentis, não um LLM: thresholds explícitos e evidência numérica em cada cartão.
09
Decisões técnicas
O padrão que mais se repete: mover custo para onde ele roda uma vez: agregação no build ao invés do request, curadoria versionada em arquivo, regra de negócio em código testado. Um job em cron a cada 15 minutos mantém a base atualizada sozinha durante a competição, com lock em arquivo para evitar sobreposição.
10
Desafios
Dado esportivo real engana se não for questionado: cobranças de disputa de pênaltis chegavam a inflar o xG de um jogo em várias unidades; o eixo do mapa de chutes estava espelhado; um campo mal nomeado publicou por um tempo um placar de prorrogação como se fosse disputa de pênaltis. Cada caso virou correção específica e, nos mais delicados, teste de regressão.
11
Próximos passos
Novas competições, mais camadas de contexto histórico e uma API pública estão em avaliação. Nada fechado ainda.
12