Modernizar con Laravel: colas, idempotencia y una migración segura

Elige un límite lo bastante pequeño para verificarlo

Una migración incremental puede reducir el alcance de cada lanzamiento, pero no está libre de riesgos. Empieza con un flujo acotado cuyas entradas, salidas y responsables se entiendan bien. Mapea el modelo de datos heredado, los efectos externos y las dependencias de informes antes de mover tráfico.

Registra la tasa de errores, la latencia de respuesta, la antigüedad de la cola y los resultados de negocio (por ejemplo, pedidos completados) como línea base. Dirige un conjunto controlado de solicitudes a la nueva implementación y conserva un camino claro de vuelta. Evita migrar a la vez el almacenamiento, el framework, los pagos y la interfaz de usuario, salvo que las dependencias lo exijan.

Mantén transaccional la escritura crítica

Valida los permisos y la entrada, y luego guarda la transición de estado mínima válida dentro de una transacción de base de datos. Usa restricciones únicas para las invariantes, como una sola referencia externa por pedido. Los bloqueos de fila o las actualizaciones condicionales pueden proteger las transiciones concurrentes cuando se usan correctamente.

Un bloqueo en Redis puede coordinar el trabajo, pero una concesión vencida, una caída o una clave con un alcance incorrecto pueden permitir que se solapen. No reemplaza a las restricciones de la base de datos. Documenta qué sistema es dueño de cada invariante y pruébalo con solicitudes simultáneas.

Despacha solo cuando los datos ya estén confirmados

Un trabajador puede ejecutarse antes de que se confirme la transacción que lo originó. Laravel permite despachar después de la confirmación, para que los trabajos no lean registros sin confirmar o revertidos. En una aplicación Laravel 12, un patrón básico es:

DB::transaction(function () use ($validated) {
    $order = Order::create($validated);
    ProcessOrder::dispatch($order->id)->afterCommit();
});

Este ejemplo está incompleto a propósito: la autorización, el manejo de solicitudes duplicadas y la validación de negocio van alrededor de él. El despacho posterior a la confirmación tampoco elimina la ventana de fallo entre la confirmación en la base de datos y la entrega a una cola externa. Para flujos que requieren una entrega duradera, considera un outbox transaccional y un publicador con reintentos.

Diseña los trabajos para una ejecución «al menos una vez»

Da por hecho que un trabajo puede ejecutarse más de una vez. Guarda una clave de idempotencia, registra las operaciones completadas y usa el mecanismo de idempotencia del proveedor externo cuando exista. No marques un trabajo como completado antes de que el efecto externo haya tenido éxito. Concilia los resultados inciertos en lugar de repetir a ciegas un cobro o un envío.

• Define tiempos de espera, límites de reintentos y esperas progresivas según la operación.
• Mantén el tiempo de espera del trabajador por debajo del intervalo de reintento de la cola, con margen para el apagado, para reducir los intentos solapados.
• Monitorea los trabajos fallidos y la antigüedad de la cola; una respuesta HTTP 202 significa «aceptado», no «completado».
• Reinicia los trabajadores de larga duración durante los lanzamientos para que carguen el código previsto.

Ensaya los fallos y la reversión

Prueba un webhook duplicado, la caída de un trabajador después de una llamada externa, un bloqueo mutuo en la base de datos, una caída de la cola y un despliegue fallido. Verifica los registros y efectos resultantes, no solo la respuesta HTTP. Agrega conciliación para el trabajo que se aceptó pero nunca se completó.

Usa cambios de esquema compatibles hacia atrás mientras ambas aplicaciones estén activas. Define las condiciones de reversión antes del lanzamiento y comprueba que la aplicación antigua pueda leer los datos escritos por la nueva. Mantén una única fuente de verdad para cada registro hasta que la sincronización esté diseñada de forma explícita.

Fuentes y lecturas recomendadas

• Laravel 12: colas, despacho posterior a la confirmación y tiempos de espera
• Laravel 12: transacciones de base de datos

Sigue explorando

Compara estrategias de renderizado o hablemos de una migración a Laravel.