Sticky work sem sticky bug: quando manter trabalho no mesmo worker e quando parar

O problema

Às vezes o backend ganha muito mantendo trabalho parecido no mesmo lugar.

Por exemplo:

• cache local aquecido
• contexto do tenant já carregado
• conexão cara já estabelecida
• estado temporário já montado

Isso leva o time a empurrar o mesmo fluxo sempre para o mesmo worker.

Pode ajudar.

O problema começa quando isso deixa de ser otimização e vira dependência.

Modelo mental

Sticky work é uma preferência operacional:

• “se der, mantém isso perto daqui”

Isso é diferente de:

• “só funciona se cair aqui”

A primeira forma captura locality.

A segunda cria bug pegajoso:

• comportamento depende do nó
• rebalancear vira caro
• failover vira susto

Stickiness boa é elástica.

Stickiness ruim é acoplamento disfarçado.

Exemplo simples

Imagine um serviço que processa uploads em várias etapas curtas.

Se etapas correlatas caem no mesmo worker por alguns minutos, o sistema reaproveita:

• cache de metadados
• conexão com storage
• contexto do arquivo

Ótimo.

Mas, se aquele fluxo só anda bem naquele worker e degrada demais ao mover:

• o scaling fica imprevisível
• o nó quente vira gargalo
• a falha de uma réplica derruba muito mais do que deveria

Nesse ponto, a stickiness já deixou de ser ajuda e virou dívida.

O erro comum

O erro comum é chamar qualquer ganho local de “otimização inteligente” e nunca mais revisitar.

Outro erro comum é usar sticky routing para esconder:

• cache mal desenhado
• partição ausente
• dependência de memória local demais

Se a arquitetura precisa desesperadamente do mesmo worker para performar, talvez o problema não seja roteamento.

Talvez seja onde o estado está morando.

O que normalmente ajuda

Normalmente ajuda tratar stickiness como:

• preferência
• janela temporária
• benefício mensurável
• estratégia com fallback

Na prática, isso costuma significar:

• afinidade soft, não hard
• TTL de associação
• rebalanceamento permitido
• métricas de skew por worker
• cold path aceitável quando a afinidade quebra

Se quebrar a stickiness destrói o fluxo, ela foi longe demais.

Como um senior pensa

Quem já viu cluster ficar torto por causa disso costuma perguntar:

• o ganho de locality é real ou só confortável?
• quanto dói quebrar a stickiness?
• esse worker está carregando contexto útil ou virou mini banco local?
• meu failover continua saudável?

Essa conversa evita sistema que escala em réplicas, mas continua preso a poucos nós quentes.

Ângulo de entrevista

Esse tema aparece em filas, jobs, workers stateful, streaming e caching local.

O entrevistador quer ver se você entende:

• que stickiness é ferramenta de locality, não desculpa para acoplamento
• que rebalanceamento e failover continuam sendo requisitos
• que o sistema precisa funcionar bem mesmo quando a afinidade quebra

Resposta forte costuma soar assim:

“Eu usaria stickiness como preferência para reaproveitar contexto quente, mas sempre com fallback saudável. Se o fluxo só vai bem no mesmo worker, eu já considero que existe dependência operacional demais naquele nó.”

Takeaway direto

Sticky work ajuda quando é preferência.

Quando vira necessidade, virou bug arquitetural.