Dispara na Mudança, Não no Relógio

O design orientado a eventos dispara quando algo muda. A mudança de estado é o evento. O evento é o gatilho.

Forma 1: a transição atômica substitui o job de reparo.

Se uma transição de estado pode deixar o sistema em um estado intermediário quebrado, o defeito está na transição, não na ausência de um job de reparo. Corrija a transição para que seja concluída de forma atômica (ou transacional). Quando a transição é concluída de forma atômica, o estado quebrado nunca existe. O job de reparo não tem nada para reparar.

# DEFEITO: transição não atômica deixa o estado quebrado
def close_pr_on_repo_private(pr_id):
pr = PR.get(pr_id)
pr.status = 'branch-forced-closed'   # passo 1: estado parcial
pr.save()                             # visível para os usuários AGORA
# ... outras etapas podem falhar ...
pr.merge_status = 'not_applicable'
pr.save()                             # passo 2: agora consistente
# Job do Sidekiq reconcilia se o passo 2 falhar

# CORREÇÃO: transição atômica; nenhum estado intermediário visível
def close_pr_on_repo_private(pr_id):
with db.transaction():
pr = PR.get(pr_id)
pr.status = 'branch-forced-closed'
pr.merge_status = 'not_applicable'
pr.save()   # ambos os campos são salvos atomicamente; nunca ficam parcialmente gravados

Forma 2: a atualização incremental substitui o recálculo completo.

Um relatório que recalcula do zero é disparado porque dados antigos + novos dados = novo resultado. Mas resultado antigo + delta = mesmo novo resultado, calculado de forma incremental. O evento: novos dados chegaram. O gatilho: atualizar o agregado apenas para os novos dados.

# DEFEITO: recálculo completo em agendamento
def nightly_totals_job():
for user in all_users():
total = sum(o.amount for o in user.orders)  # varre todo o histórico
user.total_purchases = total
user.save()

# CORREÇÃO: atualização incremental orientada a eventos
def on_order_placed(order):
order.user.total_purchases += order.amount   # apenas o delta
order.user.save()

A atualização incremental é disparada quando um pedido chega, não às 2h da manhã. Ela atualiza apenas o usuário afetado. Ela lê apenas o novo pedido, não todos os pedidos de todos os tempos. O job noturno desaparece.

Por que o Formulário 1 Revela uma Transição Quebrada

Um Formulário 1 Metered Heart revela que uma transição de estado foi deixada incompleta. O job de reparo existe porque um engenheiro notou um estado quebrado e adicionou um mecanismo de reconciliação em vez de corrigir a transição. O job de reparo: um remendo sobre uma decisão arquitetural quebrada.

MOAD-0009 como Amplificador

MOAD-0009 amplifica outros MOADs. Um job de reparo de estado que varre todos os registros para encontrar estado quebrado: MOAD-0001 (varredura O(N) ou O(N²) por execução do job). Um job de relatório que recalcula tudo do zero: MOAD-0005 (stampede de cache quando o job inicia e atinge um upstream aquecido). MOAD-0009 não prejudica apenas por si só; ele entrega outros MOADs em um agendamento.

Diagnosticar e Redesenhar

Uma equipe executa um cron job noturno às 2h da manhã. O job varre todos os pedidos de todos os usuários e recalcula do zero o valor total de compras de cada usuário. O job leva 4 horas. Às 6h da manhã, o dashboard exibe os totais atualizados. Entre 2h e 6h da manhã, o dashboard exibe os totais de ontem.