Afinidade de workload sem transformar scaling em loteria

O problema

Nem todo trabalho é igual.

Alguns workloads ganham muito quando continuam próximos de:

• uma chave
• uma partição
• um cache quente
• uma conexão já estabelecida
• um contexto já carregado

Se o sistema distribui tudo aleatoriamente o tempo inteiro, cada escala vira aposta:

• onde esse trabalho vai cair?
• vai reaproveitar algo ou reaquecer tudo?
• vai concentrar hotspot sem ninguém prever?

Scaling vira loteria.

Modelo mental

Afinidade de workload significa manter algum tipo de proximidade estável entre trabalho e recurso útil.

Essa afinidade pode ser por:

• tenant
• shard
• entidade
• partição temporal
• classe de trabalho

O objetivo não é “fixar para sempre”.

O objetivo é capturar locality quando ela reduz custo suficiente para valer o controle extra.

Exemplo simples

Imagine jobs de recomputação por tenant.

Cada job precisa ler:

• configuração do tenant
• cache local já aquecido
• conexões e partições correlacionadas

Se cada execução cai em worker aleatório:

• aquece contexto toda vez
• disputa cache com outros tenants
• gera comportamento mais variável

Se existe afinidade por tenant ou partição, o sistema reaproveita mais contexto e fica mais previsível.

Mas, se esse tenant crescer demais, também precisa rebalancear.

O erro comum

O erro comum é ir para um dos extremos:

• tudo random
• tudo rigidamente preso

No primeiro, você perde locality útil.

No segundo, cria:

• hotspot fixo
• dificuldade de rebalancear
• falha barulhenta quando um nó cai

Outro erro comum é adotar afinidade sem saber o que está sendo preservado.

Se não existe ganho claro de cache, contexto ou partição, talvez você só esteja complicando o scaling.

O que normalmente ajuda

Normalmente ajuda responder quatro perguntas:

• qual é a chave natural de afinidade?
• qual ganho real ela traz?
• quando o sistema pode quebrar essa afinidade?
• como redistribuir sem caos?

Na prática, isso costuma aparecer como:

• particionamento por chave
• hashing consistente
• workers preferenciais com fallback
• rebalanceamento controlado
• observabilidade de skew

A afinidade boa melhora previsibilidade.

A ruim só prende o sistema a uma distribuição arbitrária.

Como um senior pensa

Quem já sofreu com scaling imprevisível costuma perguntar:

• qual contexto vale a pena manter junto?
• quanto skew eu aceito antes de rebalancer?
• se um worker sumir, o trabalho reencaixa bem?
• estou usando afinidade para ganhar locality ou para esconder outra ineficiência?

Essa conversa evita backend que escala em número de réplicas, mas não escala em comportamento.

Ângulo de entrevista

Esse tema aparece em filas, jobs, multi-tenant, caching e particionamento.

O entrevistador quer ver se você entende:

• que nem toda distribuição precisa ser totalmente aleatória
• que locality também é decisão de arquitetura
• que afinidade útil precisa coexistir com rebalanceamento e tolerância a falha

Resposta forte costuma soar assim:

“Eu usaria afinidade quando ela preserva contexto ou partição de forma mensurável, mas deixaria claro como o sistema rebalanceia e quebra a afinidade quando um nó esquenta ou cai. Senão a gente troca aleatoriedade por rigidez frágil.”

Takeaway direto

Scaling não deveria depender de sorte.

Se locality importa, afinidade precisa ser desenhada.