Queime Mudança, Não Relógio

Design baseado em eventos dispara quando algo muda. A transição de estado é o evento. O evento é o gatilho.

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

Se uma transição de estado pode deixar o sistema em um estado quebrado intermediário, o defeito vive na transição, não na ausência de um trabalho de reparo. Corrija a transição para ser completada atomaticamente (ou transacionalmente). Quando a transição for completada atomaticamente, o estado quebrado nunca existirá. O trabalho de reparo não terá nada para reparar.

# DEFECT: transição não-atômica deixa estado quebrado
def close_pr_on_repo_private(pr_id):
    pr = PR.get(pr_id)
    pr.status = 'branch-forced-closed'   # etapa 1: estado parcial
    pr.save()                             # visível aos usuários AGORA
    # ... outras etapas podem falhar ...
    pr.merge_status = 'not_applicable'
    pr.save()                             # etapa 2: agora consistente
    # Job Sidekiq de reconciliação se a etapa 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 se comprometem atomicamente; nunca escrito pela metade

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

Um relatório que recalcula do zero dispara porque dados antigos + novos dados = novo resultado. Mas os dados antigos + delta = mesmo novo resultado, calculado incrementalmente. O evento: dados novos chegaram. O gatilho: atualize o agregado apenas para os novos dados.

# DEFICIÊNCIA: cálculo completo agendado
def nightly_totals_job():
    for user in all_users():
        total = sum(o.amount for o in user.orders)  # analisar todos os tempos
        user.total_purchases = total
        user.save()

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

A atualização incremental dispara quando uma compra é feita, não às 2 da madrugada. Ele atualiza apenas o usuário afetado. Ele lê apenas a nova compra, não todas as compras de todos os tempos. O job noturno desaparece.

Por que a Forma 1 Revela uma Transição Quebrada

Um Medidor de Corrente da Forma 1 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: uma correção sobre uma decisão arquitetural quebrada.

MOAD-0009 como Amplificador

O MOAD-0009 amplifica outros MOADs. Um job de reparo do estado que varre todos os registros para encontrar o estado quebrado: MOAD-0001 (O(N) ou O(N²) scan por execução do job). Um job de relatório que recalcula tudo em frio: MOAD-0005 (estampide de cache quando o job começa e atinge uma fonte upstream quente). O MOAD-0009 não machuca apenas por si só; ele entrega outros MOADs em um cronograma.

Diagnose & Redesign

Um time executa um job cron noturno às 2 da madrugada. O job escaneia todos os pedidos de todos os usuários e recomputea o total de compras de cada usuário do zero. O job leva 4 horas. Às 6 da manhã, o painel mostra totais atualizados. Entre às 2 da madrugada e às 6 da manhã, o painel mostra totais do dia anterior.