Incendio en Cambio, No en Reloj

Diseño basado en eventos dispara cuando algo cambia. El cambio de estado es el evento. El evento es el disparador.

Forma 1: la transición atómica reemplaza el trabajo de reparación.

Si una transición de estado puede dejar al sistema en un estado roto intermedio, el defecto vive en la transición, no en su ausencia de trabajo de reparación. Arregle la transición para completar de manera atómica (o transaccional). Cuando la transición se completa de manera atómica, el estado roto nunca existe. El trabajo de reparación no tiene nada que arreglar.

# DEFECT: transición no atómica deja un estado roto
def close_pr_on_repo_private(pr_id):
    pr = PR.get(pr_id)
    pr.status = 'branch-forced-closed'   # paso 1: estado parcial
    pr.save()                             # visible para los usuarios AHORA
    # ... otros pasos pueden fallar ...
    pr.merge_status = 'not_applicable'
    pr.save()                             # paso 2: ahora consistente
    # Trabajo Sidekiq de reconciliación si falla el paso 2

# SOLUCIÓN: transición atómica; ningún estado intermedio visible
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 campos se comiten atómicamente; nunca escrito a la mitad

Forma 2: la actualización incremental reemplaza el cálculo completo.

Un informe que vuelve a calcular desde cero dispara porque los datos antiguos + nuevos datos = nuevo resultado. Pero los datos antiguos + delta = mismo nuevo resultado, calculado incrementalmente. El evento: nuevos datos llegaron. El desencadenante: actualice el agregado solo para los nuevos datos.

# DEFECTO: cálculo completo programado
def nightly_totals_job():
    for user in all_users():
        total = sum(o.amount for o in user.orders)  # escaneo de todos los tiempos
        user.total_purchases = total
        user.save()

# SOLUCIÓN: actualización basada en eventos incremental
def on_order_placed(order):
    order.user.total_purchases += order.amount   # solo delta
    order.user.save()

La actualización incremental dispara cuando llega una orden, no a las 2 AM. Actualiza solo al usuario afectado. Lee solo la nueva orden, no todas las órdenes de todos los tiempos. El trabajo nocturno desaparece.

Por qué la Forma 1 Revela una Transición Rota

Un Medidor de Corazón de Forma 1 Medido revela que una transición de estado se dejó incompleta. El trabajo de reparación existe porque un ingeniero notó un estado roto y agregó un mecanismo de reconciliación en lugar de arreglar la transición. El trabajo de reparación: una solución de parche sobre una decisión arquitectónica rota.

MOAD-0009 como Amplificador

MOAD-0009 amplifica a otros MOADs. Un trabajo de reparación de estado que escanea todos los registros para encontrar el estado roto: MOAD-0001 (escaneo O(N) o O(N²) por ejecución de trabajo). Un trabajo de informe que vuelve a calcular todo frío: MOAD-0005 (estampida de caché cuando el trabajo comienza y golpea una fuente caliente). MOAD-0009 no lastima solo; entrega a otros MOADs con un horario.

Diagnóstico y Rediseño

Un equipo ejecuta un trabajo cron nocturno a las 2 AM. El trabajo escanea todos los pedidos de todos los usuarios y vuelve a computar el monto total de compras de cada usuario desde cero. El trabajo tarda 4 horas. A las 6 AM, el tablero muestra totales frescos. Entre las 2 AM y las 6 AM, el tablero muestra los totales de ayer.