Spotify

O produto do Spotify é fundamentalmente um problema de recomendação. Discover Weekly, Daily Mix, Blend, Radio, e até a ordem da sua tela de Home são todos outputs de modelo. Esse modelo é tão bom quanto os eventos que o alimentam — todo play, skip aos 3s, joinha e busca tem que cair no warehouse, limpo, na hora, toda vez.

A 500 bilhões de eventos por dia, "limpo" não é pouca coisa. A plataforma inteira do Spotify é desenhada em torno de tornar esse pipeline de eventos entediante pra que o trabalho interessante — modelos, produto, growth — tenha piso sólido.

Todo evento que o Spotify entrega é definido num schema registry. Se um cliente quer emitir TrackPlayed, ele registra o schema (campos, tipos, significado semântico) como código. O sistema de event delivery:

• Rejeita eventos que não batem com um schema conhecido
• Suporta evolução de schema backward-compatible (novos campos opcionais OK, mudanças breaking exigem nome de evento novo)
• Roteia eventos pro Pub/Sub com o schema anexado
• Materializa automaticamente uma tabela BigQuery por tipo de evento, espelhando o schema

É o mesmo padrão que Uber e Netflix redescobriram com nomes diferentes (Keystone, Schema Service da Uber). O insight: o schema do evento é a interface entre engenheiros de produto e engenheiros de dados. Entregue, tenha ownership, evolua com propósito.

O Spotify open-sourceou o Scio — um SDK Scala pro Apache Beam / Google Dataflow. A API Java do Beam é verbosa. Scio faz o Beam parecer com Spark ou Scalding: uma API fluente, tipada, funcional.

Um pipeline canônico em Scio: enriquecer eventos brutos de play com metadados de track, agregar por usuário, escrever no BigQuery.

import com.spotify.scio.bigquery._
import com.spotify.scio.{ContextAndArgs, ScioContext}

object PlayEnrichment {
  def main(cmdlineArgs: Array[String]): Unit = {
    val (sc, args) = ContextAndArgs(cmdlineArgs)

    // Lê eventos com schema validado do BigQuery (ou Pub/Sub pra streaming)
    val plays = sc.typedBigQuery[PlayEvent](args("input"))

    // Broadcast da dimensão de tracks pra join side-input
    val tracks = sc.typedBigQuery[Track]("tracks_curated").asMapSideInput

    plays
      .withSideInputs(tracks)
      .flatMap { (p, ctx) =>
        ctx(tracks).get(p.trackId).map { t =>
          EnrichedPlay(p.userId, p.trackId, t.artistId, t.genre, p.ms)
        }
      }
      .toSCollection
      .saveAsTypedBigQueryTable(args("output"))

    sc.run()
  }
}

O mesmo código roda como batch (sobre a tabela BigQuery de ontem) ou streaming (sobre o tópico Pub/Sub). Um único código, dois modos de execução. É esse o ponto do Beam.

Diferente da Netflix (S3 + Iceberg + Trino) ou do Airbnb (S3 + Spark + Presto), o Spotify fez uma aposta opinativa em BigQuery como warehouse. Funciona porque:

• Separação de storage e compute é nativa: eles não rodam cluster, submetem queries.
• Streaming inserts aterrissam eventos do Pub/Sub com segundos de latência.
• BigQuery + Dataflow são da mesma família de produto — sem impedance mismatch.

O trade é vendor lock-in. O Spotify aceita porque o custo operacional de rodar Presto/Spark/HDFS na escala deles exigiria um time grande de infra. BigQuery deixa 30 engenheiros de dados servirem 3.000 usuários internos. Essa conta vence.

Não copie isso sem fazer a conta. BigQuery na sua escala pode ser uma ordem de magnitude mais caro que um lakehouse S3 + Trino. Ou pode ser mais barato. Roda os números.

O Spotify open-sourceou o Backstage — um portal de desenvolvedor que cataloga todo serviço, pipeline, dataset e dashboard da empresa. Não é uma ferramenta específica de dados, mas resolveu um problema muito de dados:

• "Qual pipeline produz a tabela user_daily_active?"
• "Quem é dono do schema do evento TrackPlayed?"
• "Quais dashboards downstream quebram se eu mudar esse campo?"

Com 500 eventos × 3.000 usuários × 1.000 pipelines, descoberta não é problema de UX — é existencial. O Backstage indexa tudo e torna o grafo de ownership atravessável. Mesmo problema que o Airbnb resolveu com Dataportal, o LinkedIn com DataHub. Ferramentas diferentes, mesma lição: sua plataforma de dados precisa de um catálogo ou vai colapsar sob o próprio peso.

• Schema é o contrato. Se seu pipeline de eventos aceita qualquer coisa, ele aceita tudo — inclusive o cliente quebrado de amanhã. Entregue um schema registry (Avro, Protobuf, JSON Schema, tanto faz) antes do seu terceiro pipeline.
• Um código, dois modos. Beam / Scio / Spark Structured Streaming prometem a mesma coisa: batch e streaming do mesmo código. Onde puder, aceite a promessa — vai evitar uma classe inteira de bugs de produção.
• BigQuery vs lakehouse é decisão de negócio, não técnica. BigQuery é incrível até deixar de ser. Lakehouse é portável mas tem piso de ops. Modele a curva de custo de 3 anos; não discuta no Twitter.
• O catálogo É a plataforma. Você não tem uma plataforma de dados até que outra pessoa consiga achar o dataset. Backstage, DataHub, Amundsen ou uma wiki bem cuidada — escolha uma e ponha gente pra manter.