Orquestación de Ciclos de Evaluación
El motor de evaluación de desempeño dentro de una plataforma de RR.HH. interna. Activar un ciclo bloquea su lista de participantes, transiciona cada evaluación dependiente y encola las notificaciones de los evaluadores en una sola transacción — y luego un relay las entrega después, con reintentos, en lugar de enviar nada dentro de la petición que las originó.
En Producción
El dispatch es una sola transacción. Un bloqueo de fila sobre el ciclo rechaza la transición si ya no es un borrador, el ciclo y cada evaluación dependiente cambian de estado juntos, y las notificaciones de los evaluadores se escriben en un outbox en el mismo commit — de modo que una caída a mitad del dispatch no puede dejar ni un ciclo a medio activar ni una notificación sin el cambio de estado que la respalda.
Nada se entrega dentro de la petición. Un relay consulta el outbox y reclama trabajo en una sola sentencia — un CTE que selecciona una fila elegible con FOR UPDATE SKIP LOCKED, marcándola como en proceso e incrementando su conteo de intentos en el mismo viaje a la base — así los workers concurrentes ni se bloquean entre sí ni procesan un evento dos veces.
La deduplicación es una restricción de la base de datos, no lógica de aplicación. Un índice único parcial sobre tenant, tipo de evento, agregado y el id del evaluador leído desde el payload JSONB hace imposible insertar una notificación de dispatch duplicada, haga lo que haga el código que la invoca.
El fallo es acotado y legible. Un evento se reintenta hasta cinco veces con backoff limitado a cinco minutos, lleva su último error en la propia fila y termina en un estado final de fallo en vez de girar indefinidamente — mientras su marca de disponibilidad funciona como el reloj de visibilidad diferida por el que el relay ordena la cola.
Cada tabla del pipeline está acotada por tenant mediante clave foránea, y la consulta de reclamación se sirve con un índice exactamente sobre las columnas que filtra y ordena.
Las trazas y métricas se exportan por OTLP, con un middleware que atribuye los spans al usuario, al tenant y al rol que hicieron la petición — y los normaliza al patrón de ruta coincidente en lugar de la ruta cruda, manteniendo los nombres de span con baja cardinalidad.