LAB_

Pruebas reproducibles. Límites explícitos.

Experimentos de backend con el código, entorno, parámetros y resultados necesarios para revisar qué ocurrió y repetir la prueba.

02experimentos activos

02ejecuciones publicadas

✓reproducible

¿Qué ocurre cuando se llena la cola LISTEN/NOTIFY de PostgreSQL?

Dos conexiones, una transacción abierta y una cola de 512 KiB: reproducción de la saturación y recuperación de notificaciones en PostgreSQL 17.11.

HIPÓTESIS

Un listener con una transacción abierta puede impedir la limpieza de la cola; terminar esa transacción debería permitir recuperar la entrega.

ENVÍOS EXITOSOS64

ENVÍOS FALLIDOS36

OCUPACIÓN MÁXIMA100%

TRAS COMMIT0%

ENTORNO Y PROCEDIMIENTO_

Docker Compose · PostgreSQL 17.11 · 64 páginas de 8 KiB · 100 intentos con payloads de 7,000 caracteres más el número de envío. LISTEN confirmado antes de BEGIN; emisor en autocommit.

SEÑALES OBSERVADAS_

idle in transaction
too many notifications in the NOTIFY queue
pg_notification_queue_usage(): 0 → 1 → 0

CONCLUSIÓN_ La ocupación alcanzó el 100%. Tras el COMMIT del listener bajó a cero y un nuevo mensaje se envió y recibió correctamente, sin reiniciar PostgreSQL.

Límite: una ejecución local con una base de datos y una cola reducida. Los 64 envíos exitosos dependen del payload; no se midieron latencias, rendimiento de disco ni una cola de 8 GiB.

Ver procedimiento y resultados →Pool de conexiones PostgreSQL →

¿Puede un motor de webhooks vaciar la cola después de perder un worker y pausar Redis?

Una prueba de 10,000 eventos y 20,000 entregas sometió el flujo durable a fallos deliberados mientras medía estados finales, duplicados, firmas y crecimiento del backlog.

HIPÓTESIS

Si PostgreSQL conserva el estado autoritativo y el outbox puede reconciliar el trabajo, matar un worker y pausar Redis no deberían dejar entregas pendientes ni romper las invariantes de seguridad.

EVENTS10,000

DELIVERIES20,000

DELIVERED19,600

FAILED200

DEAD-LETTER200

PENDING0

Gráfico medido del crecimiento y vaciado de la cola durante 20,000 entregas — El backlog observado alcanzó 12,420 entregas y terminó en cero. La línea discontinua marca el final de la ingesta; la franja sombreada, la pausa de Redis.

FALLOS INYECTADOS_

Un proceso worker fue terminado mientras poseía un claim.
El Redis aislado fue pausado durante tres segundos.
El escenario incluyó respuestas HTTP permanentes y transitorias.

INVARIANTES_

0 pares Event/Endpoint duplicados
0 firmas HMAC inválidas
0 entregas pendientes al finalizar

CONCLUSIÓN_ La ejecución respaldó la hipótesis en este entorno: el claim interrumpido fue recuperado, la cola volvió a drenar y todos los estados finales coincidieron con el escenario.

Límite: es una ejecución local controlada, no un SLA ni una estimación de throughput en producción. Las latencias incluyen cola y reintentos.

Ver caso técnico →Leer reporte completo ↗Ver repositorio →

NOTES_001

Cómo están construidos estos análisis

Hipótesis primero

Cada prueba comienza con una pregunta que se puede refutar.

Alcance explícito

Cada pieza indica si es una guía, un análisis de fuentes o un experimento medido.

Evidencia verificable

Los experimentos se publicarán con entorno, parámetros y resultados revisables.