Plataforma de Dados Meteorológicos

Arquitetura

1. Provedores meteorológicos

   modelos NWP, radar e satélite do BoM, alertas
2. Argo Workflows

   Kubernetes · GRIB2 → Zarr · PMTiles
3. Storage

   Cloudflare R2 · Supabase · OVH S3
4. Workers de borda

   KV · D1 · entrega R2-first
5. Mapa e clientes

   runtime MapLibre · apps na Vercel · APIs

A plataforma

A Jane's Weather produz previsões, imagens de radar e satélite e alertas para aplicativos de consumo e para clientes como o FarmOnline Weather da ACM. A produção de dados roda como Argo Workflows e CronJobs Kubernetes em um cluster OVH em Sydney: rodadas de modelo em GRIB2 são convertidas em Zarr, imagens de radar e Himawari viram PMTiles e pirâmides de tiles a cada cinco minutos, alertas do Bureau of Meteorology são ingeridos em PostGIS. A entrega é storage-first: os frontends resolvem artefatos versionados no Cloudflare R2 via Workers, e um Worker provedor de dados usa D1 e KV para catálogo e autenticação antes de recorrer às APIs em Kubernetes.

O mapa

Minha primeira responsabilidade foi o mapa. Projetei e construí o runtime do mapa meteorológico que hoje é a experiência de mapa canônica da plataforma e de quem a incorpora, como o FarmOnline Weather: uma aplicação React sobre MapLibre com PMTiles para mapas base e camadas meteorológicas, dois modos (previsão, guiado pela linha do tempo e pelos modelos; agora, com prioridade ao radar mais satélite, observações e alertas), uma abstração compartilhada de camadas temporais com pré-carregamento, e um contrato de incorporação URL-first para que sites parceiros controlem modo, modelo, camadas e viewport por parâmetros de consulta.

O mapa é só metade. Também escrevi o lado de processamento que o alimenta: o modelo de configuração de camadas, os scripts Python que transformam previsões em grade Zarr em isolinhas PMTiles, e os workflows Argo que publicam artefatos de previsão, radar, Himawari, alertas e mapas base no R2 em agenda, além da ferramenta de captura headless que renderiza imagens estáticas de previsão para o site principal.

Operando a plataforma inteira

Depois que a plataforma passou para a ACM e migrou entre nuvens, o conhecimento de como ela se encaixava estava espalhado por repositórios, um espaço Confluence desatualizado e a cabeça das pessoas. A equipe da Territorial assumiu a plataforma inteira, e eu lidero esse trabalho. Construímos o programa de documentação primeiro: um site VitePress organizado por fronteira de sistema, com cada afirmação rastreada ao código ou à configuração viva e cada lacuna declarada explicitamente. Isso revelou riscos concretos (o cluster de desenvolvimento servindo tráfego de produção, um cronjob de ingestão cujo código implantado vinha de um repositório diferente do que todos supunham, credenciais sem caminho de rotação) e os transformou em issues acompanhadas.

Depois, monitoramento. Os exit handlers do Argo só avisavam quando um pipeline dizia ter falhado; nada verificava se os artefatos estavam de fato frescos e acessíveis. Implantamos o Sentinel com uma suíte que hoje cobre os Workers de borda, as APIs em Kubernetes, o proxy do BoM, as fontes dos modelos e os três frontends, usando limiares de defasagem calculados independentemente a partir dos horários observados de chegada dos modelos, e não das flags da própria plataforma. No dia a dia a equipe cuida de desenvolvimento e manutenção das APIs e frontends, secrets e rollouts no Kubernetes, investigação de incidentes e postmortems (um rate limit do ECMWF, uma migração de URL do GEM, um pico de gastos na Vercel, um crash loop por corrupção de NaN na API de consumo).