Como você lida com uma hot key ou hot row sob forte contenção?

Question

IT Interview Practice · Accepted Answer

**Pare de canalizar todo o tráfego para uma única chave: divida a hot key em N sub-chaves (contadores com sharding), coalesça leituras duplicadas, sirva de um cache local e agrupe escritas para que uma linha não seja atualizada a cada requisição.** Um único contador de "likes" em um post viral pode receber 50k escritas/seg — uma linha vira um gargalo de serialização à medida que toda transação disputa o mesmo lock.

## Fan-out em vez de uma linha contendida

```text
                 50k inc/sec on post:123
                          │
             hash(request) % N   (split the key)
        ┌────────┬────────┬────────┬────────┐
        ▼        ▼        ▼        ▼        ▼
   likes:123:0  :123:1  :123:2  :123:3  :123:4   ← sharded counters
        └────────┴───┬────┴────────┴────────┘
                     ▼
             SUM on read = total     (read fans in)
```

## Técnicas

- **Contador com sharding / divisão de chave.** Escreva em `likes:123:{0..N}` escolhido aleatoriamente; a contagem verdadeira é o `SUM`. Isso transforma uma linha quente em N linhas mais frias, cortando a contenção de lock em ~N. As leituras pagam um pequeno custo de fan-in.
- **Coalescência de requisições (single-flight).** Se 10k requisições querem a mesma chave de uma vez, deixe **uma** bater no DB e faça o resto esperar por esse resultado em andamento. Impede que uma stampede de cache-miss esmague a linha.
- **Cache local (in-process).** Cacheie o valor quente em cada nó do app por um TTL curto (ex. 1s). Para uma chave read-hot, isso colapsa milhares de leituras/seg em um único refresh — aceitando leve staleness.
- **Batching de escritas.** Bufferize incrementos na memória e faça flush de `+= 500` uma vez por segundo em vez de 500 updates individuais. Um update de linha por segundo em vez de 500 remove a contenção por completo.

## Perspectiva de entrevista

O entrevistador quer ver você diagnosticar **onde está a contenção** e casar a correção com read-hot vs write-hot. Read-hot → cache + coalescência; write-hot → contadores com sharding + batching. Boa resposta lista técnicas; ótima resposta nota que sharding troca **custo de leitura por escalabilidade de escrita**, e que batching/caching trocam **frescor por throughput**.

**Trade-offs e armadilhas:** contadores com sharding tornam totais exatos em tempo real mais difíceis (você soma os shards) e complicam a lógica de "decrementar abaixo de zero". Caches locais divergem entre nós — ok para uma contagem de likes, errado para um saldo bancário. Batching arrisca perder escritas bufferizadas se um nó cai antes do flush, então serve para contadores idempotentes/aproximados, não para dinheiro. Escolha a mitigação que as necessidades de consistência dos dados permitirem.

Fan-out em vez de uma linha contendida

Técnicas

Perspectiva de entrevista

Perguntas relacionadas