Como a PostHog construiu uma análise de produto open source que aguenta escala

Um MVP em Django e Postgres no Heroku

A primeira versão foi feita pelo cofundador Tim Glaser em quatro semanas, durante a Y Combinator. Era um app Django simples, que consultava os eventos pelo ORM do Django, rodava no Postgres do Heroku e subia com um clique.

Essa simplicidade trouxe os primeiros usuários. Quando mais times adotaram o produto e passaram a mandar mais eventos, o Postgres do Heroku chegou ao limite e as consultas ficaram lentas.

Fontes:posthog.com

A troca do Postgres pelo ClickHouse nos eventos

Em 2021 o time testou Pinot, Presto, Druid, TimescaleDB, Citus e ClickHouse olhando velocidade, facilidade de hospedar por conta própria e linguagem de consulta. O ClickHouse saiu cerca de dez vezes mais rápido, e o cluster de teste virou o de produção. Segundo a PostHog, o Postgres sofria a partir de uns 10 mil usuários ativos por mês.

Os dois bancos rodaram juntos, recebendo os mesmos dados, e cada recurso foi migrado de cada vez atrás das próprias feature flags. Quando tudo tinha mudado, pararam de gravar eventos no Postgres. Nem tudo foi tranquilo: centenas de mutations por minuto, bem acima do que o ClickHouse recomenda, derrubaram o serviço uma vez.

Fontes:posthog.com posthog.com

Rust e Kafka na entrada dos eventos

Hoje o caminho mais pesado fica fora do app Django. Serviços em Rust recebem os eventos, avaliam as feature flags e ingerem as gravações de sessão, e o Kafka é o barramento central que liga a entrada ao armazenamento.

Um worker de CDP em Node.js processa os eventos na chegada e manda para os destinos. O Django continua servindo o app e a API, e o handbook deixa o Rust para os serviços de alta escala.

Fontes:posthog.com posthog.com

Três ferramentas para trabalho em segundo plano

A PostHog usa o Celery só para tarefas pequenas e rápidas, porque o handbook diz que ele pode falhar em fluxos maiores ou longos. Trabalhos médios e grandes vão para outro lugar.

O Temporal cuida dos fluxos que o usuário vê e dos críticos, pela garantia de execução exatamente uma vez, e sai bem mais barato que o Dagster em tarefas recorrentes. O Dagster fica com os jobs internos de dados, onde a linhagem dos dados e os testes pesam mais.

Fontes:posthog.com

A PostHog Cloud na AWS

Na PostHog Cloud, os serviços do app rodam num cluster Kubernetes no EKS da AWS, e os bancos ficam à parte. O ClickHouse é um cluster próprio em EC2, com shards e réplicas, o Postgres roda no Aurora com PgBouncer na frente, e as gravações de sessão e exportações ficam no S3.

Fontes:posthog.com