Meta Threads: 100 milhões de usuários em 5 dias

01 · CONTEXTO

Um lançamento anunciado quase sem aviso

O Threads foi lançado pela Meta em 5 de julho de 2023 e passou de cem milhões de cadastros nos cinco primeiros dias. A fonte deste caso é o texto de engenharia da própria Meta sobre a infraestrutura por trás desse lançamento.

Uma equipe pequena construiu o produto em cerca de cinco meses de trabalho técnico, e as equipes de infraestrutura souberam da data com apenas dois dias de antecedência. Segundo o texto, a infraestrutura não foi feita sob medida para o Threads: vinha sendo construída para muitos produtos da empresa.

O texto destaca dois componentes: o ZippyDB, um armazém chave-valor distribuído, e o Async, uma plataforma de funções assíncronas. As próximas seções tratam de cada um.

1. Publicações e respostas do Threads vivem no TAO, apoiado em MySQL, que guarda o grafo social.

2. O ZippyDB, contraparte chave-valor do MySQL, guarda contadores, estado e ranqueamento de feed e busca.

3. O Async executa trabalhos que não precisam bloquear o usuário.

02 · CAPACIDADE

ZippyDB: duas alavancas para crescer rápido

O ZippyDB roda sobre um pool comum de hardware. Máquinas novas adicionadas ao serviço são absorvidas em poucas horas.

Mas aprovar e realocar capacidade de ponta a ponta ainda podia levar da ordem de um par de dias. A equipe também se apoiava em multilocação, que deixa keyspaces com demandas complementares compartilharem os mesmos hosts sem que um impacte o nível de serviço do outro.

Havia ainda folga no pool. Deslocar alocações não usadas entre keyspaces e deixar os hosts mais ocupados permite que um keyspace cresça quase de imediato e se sustente por um curto intervalo.

03 · RESHARDING

Aumentar o número de shards sem parar os clientes

O protocolo de resharding do ZippyDB aumenta o fator de sharding (a escala horizontal) de um caso de uso sem indisponibilidade para os clientes. O desenho usa dois níveis: os clientes aplicam hash às chaves para shards lógicos, que são mapeados para um conjunto de shards físicos. É um exemplo de sharding de banco de dados.

1. Os clientes aplicam hash às chaves para shards lógicos, mapeados para os shards físicos do mapeamento original.

2. Quando o caso de uso cresce, provisiona-se um novo conjunto de shards físicos.

3. O novo mapeamento lógico-físico é instalado nos clientes por mudança de configuração ao vivo, sem indisponibilidade.

4. O resharding usa um modelo coordenador-trabalhador, e os executores movem atomicamente cada shard lógico do mapeamento original para o novo.

5. Ao migrar todos os shards lógicos, o resharding termina e o mapeamento original é removido.

O modelo coordenador-trabalhador foi desenhado para ser escalável na horizontal e permitir acelerar o resharding quando preciso, como no lançamento do Threads. Casos de uso novos costumam começar pequenos e passar por resharding conforme o crescimento exige; aqui, a equipe viu que precisava preparar o Threads para um crescimento de cem vezes fazendo resharding proativo.

O resharding terminou a tempo da abertura do tráfego, à meia-noite no horário do Reino Unido.

04 · TRABALHO ASSÍNCRONO

Async: seguir milhões de pessoas sem travar a entrada

O Async é a plataforma de funções serverless da Meta e consegue adiar computação para horários de menor uso. Os trabalhos típicos são os que não exigem bloquear um usuário ativo e podem rodar de alguns segundos a várias horas depois da ação.

No Threads, o Async permitiu que o novo usuário seguisse quem já seguia no Instagram. Executar esse seguimento via Async evita bloquear a entrada do usuário.

1. O novo usuário pede para seguir no Threads quem já segue no Instagram.

2. O pedido vira trabalho enfileirado no Async, o que evita bloquear a entrada do usuário.

3. Quando celebridades entraram, milhões de pessoas podiam ficar na fila para segui-las.

4. A execução é gerida dentro de limites de taxa para não sobrecarregar os serviços a jusante.

5. O Async ajusta o fluxo à própria capacidade e à de dependências como o banco do grafo, sem intervenção manual.

O volume de jobs superou em várias ordens de magnitude a expectativa inicial. Mesmo assim, o Async o absorveu, enfileirando-o para execução controlada, e as notificações correspondentes também passaram por ele.

05 · LIÇÕES

O que escalou sozinho e onde houve esforço

A fonte aponta uma infraestrutura compartilhada que resistiu ao teste do tempo e um alto grau de automação. Salvo o esforço para garantir capacidade com pouco aviso, redistribuição, balanceamento e escala de cargas ocorreram de forma automática e transparente.