Contador distribuído (likes e views de celebridade)

01 · O PROBLEMA

Um número que todo mundo incrementa

O contador de curtidas de uma postagem é o exemplo que a própria documentação do Firestore usa para documentos que funcionam como contador, ao lado dos favoritos de um item.

O limite aparece quando o contador é um único documento. No Firestore não é possível atualizar um único documento a uma taxa ilimitada e, com incrementos frequentes o bastante, surge contenção nas atualizações desse documento.

1. Cada curtida chega à API de curtidas.

2. A API incrementa um único documento, que guarda o valor do contador.

3. Quando os incrementos ficam frequentes o bastante, as atualizações desse documento passam a disputar entre si.

4. Sob volume alto e sustentado de operações simultâneas, o documento único pode virar um ponto quente.

A documentação de escala descreve o mesmo ponto quente: volumes altos e sustentados de operações simultâneas em um único documento podem causar um ponto quente nele, e a recomendação é alterar o modelo de dados para dividir ou replicar os dados entre vários documentos.

02 · FRAGMENTAR O CONTADOR

Muitos documentos, uma soma

A solução da documentação é o contador distribuído: cada contador é um documento com uma subcoleção de fragmentos, e o valor do contador é a soma dos valores dos fragmentos. É a ideia de fragmentar a escrita aplicada a um único número.

1. Cada curtida chega à API de curtidas, como antes.

2. Para registrar a curtida, a API escolhe um fragmento aleatório e incrementa só ele.

3. A curtida seguinte sorteia outro fragmento, e as escritas se distribuem entre documentos diferentes.

4. O valor do contador é a soma dos valores dos fragmentos.

5. A vazão de escrita cresce de forma linear com o número de fragmentos.

Para incrementar, escolhe-se um fragmento aleatório. A vazão de escrita cresce de forma linear com o número de fragmentos: um contador distribuído com 10 fragmentos suporta 10 vezes mais escritas que um contador tradicional. No exemplo de código da documentação, cada fragmento suporta ser incrementado uma vez por segundo, por isso são necessários vários fragmentos para permitir incrementos mais frequentes.

03 · O PREÇO DA LEITURA

Fragmentar empurra o custo para quem lê

A documentação aponta o custo do número de fragmentos. Com poucos fragmentos, algumas transações precisam repetir antes de ter sucesso e a escrita fica mais lenta; com fragmentos demais, as leituras ficam mais lentas e mais caras.

Ler o valor custa mais a cada fragmento acrescentado: o custo de leitura cresce de forma linear com o número de fragmentos, porque toda a subcoleção de fragmentos precisa ser carregada.

Na prática, isso vira uma pergunta de dimensionamento: quanto o contador recebe de escrita e quanto ele é lido.

04 · TOTAL CONSOLIDADO E JOBS

Ler um número pronto

Uma forma de compensar o custo de leitura é manter o total em um documento de total separado, atualizado em cadência mais lenta, e fazer os clientes lerem esse documento. A contrapartida é que os clientes precisam esperar a atualização desse documento, em vez de calcular o total lendo todos os fragmentos logo após cada atualização.

1. As curtidas continuam indo para os fragmentos, como antes.

2. Ler o valor somando os fragmentos exige carregar toda a subcoleção, e o custo cresce de forma linear com o número deles.

3. O documento de total é atualizado em cadência mais lenta que as escritas; neste desenho, quem faz isso é o job de consolidação.

4. Os clientes leem o total desse documento, em vez de somar os fragmentos.

5. A contrapartida é esperar a atualização do documento de total, em vez de calcular o total logo após cada atualização.

Um job agendado é um jeito natural de implementar essa cadência mais lenta. O intervalo entre execuções é uma decisão de produto: quão atrasado o número pode aparecer para quem lê. O total passa a convergir para a soma dos fragmentos com atraso, uma troca típica de consistência eventual.

05 · ALTERNATIVAS E FECHAMENTO

Fragmentar, replicar ou incrementar em memória

A documentação do Firestore no modo Datastore indica duas saídas: use fragmentação ou replicação para lidar com pontos quentes. A replicação guarda N cópias da mesma entidade e permite uma taxa de leitura N vezes maior; a fragmentação serve para escrever a uma taxa maior e quebra a entidade em partes menores.

Fora do Firestore, o padrão de contador do Redis usa operações atômicas de incremento: a ideia é enviar um comando INCR ao Redis a cada operação.