Gestionar los retiros y la fila de SMS en caso de fracaso en el envío (arquitectura y código)

El reinicio de un mensaje de texto de retroceso (Retry) después de un fracaso sin analizar la causa puede provocar una superfacturación masiva (enviar 15 veces el mismo mensaje al cliente), el bloqueo de su cuenta por el mecanismo anti-spam de la pasarela, o la inundación de una red ya saturada.

Aquí está cómo diseñar una gestión inteligente de fallos de envío de SMS en un entorno de producción, con filas de espera resistentes.

Imagínese que Marruecos Telecom (IAM) está sufriendo un micro-corte de red de 2 minutos. Su sistema está tratando de enviar 1000 alertas transaccionales urgentes. La API devuelve un timeout o un error servidor HTTP 503. Si su código hace un simple while(failed) { retry(); }, usted va a bombardear la API de 1000 solicitudes adicionales cada segundo. Tan pronto como la red se restablezca, la fila de espera de la pasarela recibirá 50.000 solicitudes de un golpe, lo que probablemente lo hará colapsar de nuevo.

Antes de considerar un Retry, su código debe leer el código de error HTTP o el estado DLR de la API.

Nunca repita (Error Permanente): - HTTP 400: El número de destino está mal formatado. - HTTP 401 / 403: Su clave de API ha expirado o el Sender ID está bloqueado. - DLR Failed: El operador confirma que el número no existe.

Cuándo reiniciar (Error Temporal): - HTTP 429: Has golpeado el límite de velocidad (Rate Limit). - HTTP 500 / 502 / 503: La pasarela SMS o la conexión de red marroquí está temporalmente indisponible.

El Exponencial Backoff es un algoritmo que distancia el tiempo entre cada intento de reinicio. En lugar de intentarlo de nuevo cada segundo, vuelve a intentarlo después de 2 segundos, luego 4, luego 8, luego 16. Se añade un "Jitter" (una variación aleatoria) para evitar que todos los procesos de su servidor realicen el reinicio exactamente en el mismo microsegundo (causando un nuevo pico).

En las arquitecturas modernas, no se gestiona el retry en el controlador HTTP. Pulsamos el mensaje en un Message Broker (como Redis) y dejamos que un Worker se encargue de ello.

En PHP (Laravel Queues) Laravel gestiona el backoff exponencial de manera elegante directamente en las propiedades de sus "Jobs".

namespace App\Jobs;

use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Bus\Dispatchable;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Queue\SerializesModels;

class SendSmsNotification implements ShouldQueue
{
    use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;

    public $phoneNumber;
    public $message;

    // Nombre maximal de tentatives (ex: abandonner après 5 essais)
    public $tries = 5;

    // Algorithme de recul : réessayer après 2s, 10s, 30s, 60s
    public function backoff()
    {
        return [2, 10, 30, 60];
    }

    public function handle()
    {
        $response = EnvoiSmsApi::send($this->phoneNumber, $this->message);

        // Si l'API renvoie un 400 (erreur permanente), on abandonne tout de suite
        if ($response->status === 400) {
            $this->fail(new \Exception('Numéro invalide, abandon.'));
            return;
        }

        // Si c'est une erreur 503, la fonction va naturellement throw une exception
        // et Laravel replacera le Job dans la file d'attente avec le backoff prévu.
        if (!$response->successful()) {
            throw new \Exception('Erreur temporaire API.');
        }
    }
}

La regla de caducidad de la OTP Si gestiona el envío de códigos OTP para autenticación 2FA, un retry puede ser peligroso. Si el SMS llega 15 minutos más tarde después de 4 retiros de red, el código generado en su base de datos ya ha caducado, generando frustración en el cliente. Para OTP críticos, limite las tries a un máximo de 2, y si eso falla, implemente un Fallback empresarial (proponer una llamada de voz o un [enviar WhatsApp]/fr/blog/whatsapp-pot-vs-sm-s-maroc/)) directamente en la interfaz del usuario, en lugar de reenviar el SMS en silencio.