Fire on Change, Not on Clock

El diseño orientado a eventos se activa cuando algo cambia. El cambio de estado es el evento. El evento es el disparador.

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

Si una transición de estado puede dejar el sistema en un estado intermedio roto, el defecto reside en la transición, no en la ausencia de un trabajo de reparación. Corrige la transición para que se complete de forma atómica (o transaccional). Cuando la transición se completa atómicamente, nunca existe un estado roto. El trabajo de reparación no tiene nada que reparar.

# DEFECTO: la 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
# Job de Sidekiq reconcilia si falla el paso 2

# FIX: transición atómica; sin 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 guardan de forma atómica; nunca quedan a medias

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

Un informe que se recalcula desde cero se ejecuta porque datos antiguos + datos nuevos = nuevo resultado. Pero resultado antiguo + delta = mismo nuevo resultado, calculado de forma incremental. El evento: llegaron datos nuevos. El disparador: actualizar el agregado solo con los datos nuevos.

# DEFECTO: recálculo completo programado
def nightly_totals_job():
for user in all_users():
total = sum(o.amount for o in user.orders)  # escanea todo el historial
user.total_purchases = total
user.save()

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

La actualización incremental se dispara cuando llega un pedido, no a las 2 AM. Actualiza solo al usuario afectado. Lee solo el nuevo pedido, no todos los pedidos de todos los tiempos. El trabajo nocturno desaparece.

Por qué el Formulario 1 revela una transición rota

Un Formulario 1 Metered Heart revela que una transición de estado quedó incompleta. El trabajo de reparación existe porque un ingeniero detectó un estado roto y añadió un mecanismo de reconciliación en lugar de corregir la transición. El trabajo de reparación: un parche sobre una decisión arquitectónica rota.

MOAD-0009 como amplificador

MOAD-0009 amplifica otros MOADs. Un trabajo de reparación de estado que escanea todos los registros para encontrar estado roto: MOAD-0001 (escaneo O(N) u O(N²) por ejecución del trabajo). Un trabajo de informe que recalcula todo en frío: MOAD-0005 (estampida de caché cuando el trabajo inicia e impacta un upstream caliente). MOAD-0009 no solo causa daño por sí mismo; entrega otros MOADs según un horario.

Diagnosticar y rediseñar

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