Como o Pinterest conseguiu escalar até 11 milhões de usuários com 6 engenheiros

A jornada de escalabilidade do Pinterest

O processo de escalabilidade do Pinterest se divide em quatro fases:

1. Era da autodescoberta: uma pequena equipe de engenharia cuidava da prototipagem rápida e das exigências de produto em constante evolução.
2. Era da experimentação: o crescimento acelerado no número de usuários exigiu expansão rápida, mas resultou em um sistema complexo e frágil.
3. Era da maturidade: a arquitetura foi simplificada com o uso de tecnologias maduras e escaláveis, como MySQL, Memcache e Redis.
4. Era da regressão: depois de adotar a arquitetura adequada, o crescimento continuou por meio de escalabilidade horizontal.

Tecnologias principais

O Pinterest priorizou tecnologias com foco em confiabilidade, facilidade de compreensão e escalabilidade:

• MySQL: banco de dados relacional estável e fácil de manter.
• Memcache: faz cache em memória dos dados acessados com frequência para aliviar as leituras no banco de dados.
• Redis: armazenamento de dados flexível capaz de lidar com várias estruturas de dados.
• Solr: plataforma de busca pronta para uso rapidamente.

Escalando o banco de dados: clustering vs sharding

O Pinterest considerou duas abordagens para distribuir o processamento do banco de dados:

Clustering

• Quando os dados chegam, o sistema determina o nó ideal e replica os dados em vários nós.
• Tem vantagens como escalabilidade automática, facilidade de configuração e garantia de disponibilidade dos dados, mas também desvantagens como complexidade, falta de maturidade e dificuldade de upgrade.

Sharding

• Os dados são divididos em pequenos blocos, e cada bloco é colocado em um servidor independente.
• Tem vantagens como arquitetura simples, escalabilidade independente e propriedade de dados bem definida, mas também desvantagens como impossibilidade de joins e transações no nível do banco de dados, além de maior complexidade na aplicação.

O Pinterest escolheu sharding devido a experiências negativas com clustering.

Transição para uma arquitetura de sharding

O Pinterest fez a transição gradualmente para sharding durante um período de congelamento de funcionalidades:

1. Eliminação de joins: todos os joins do MySQL foram removidos, com uso de desnormalização de dados e cache.
2. Sharding baseado em ID: o sharding foi feito com base em IDs de 64 bits para simplificar o roteamento dos dados.

Desvantagens do sharding e soluções

• Scripts de migração: o processo de transferir dados para a infraestrutura de sharding consumia muito tempo.
• Lógica da aplicação: foi necessário manter a consistência dos dados devido à ausência de joins e transações no nível do banco de dados.
• Alterações de schema: era preciso planejar e aplicar mudanças de schema em todos os shards.
• Geração de relatórios: os relatórios precisavam ser gerados consolidando vários shards.

Lições aprendidas

Principais lições da jornada de escalabilidade do Pinterest:

• Simplicidade importa: escolher tecnologias fáceis de entender ajuda a resolver problemas e reduzir riscos.
• Escalabilidade em primeiro lugar: em ambientes de crescimento acelerado, vale priorizar escalabilidade mesmo ao custo de abrir mão de alguns recursos do banco de dados.
• Projetar para escalabilidade horizontal: escolher uma arquitetura que permita adicionar recursos à medida que a base de usuários cresce.