Cómo evitar el efecto dominó en microlitos HTTP sin agregar complejidad extrema

Parte 1: https://dantofema.ar/blog/por-que-los-microlitos-que-se-comunican-por-http-no-escalan-como-imaginas

En la segunda iteración del diseño, los equipos suelen darse cuenta: “paramos de compartir base de datos, pero un servicio sigue dependiendo del otro”. La caída de vídeos impacta usuarios; la latencia entre servicios se acumula; y lo que debería escalar independiente termina condicionado por terceros.

Antes de pensar en mensajería distribuida o colas complejas, hay mecanismos simples y muy aplicables desde PHP/Laravel para reducir el impacto.

1. Cachear respuestas remotas

Ideal para datos lentos de cambiar, como el total de vídeos. Evita bombardear al servicio remoto y lo protege de picos.

public function getCachedVideoCount(int $userId): int
{
    return cache()->remember("video-count-{$userId}", 300, function () use ($userId) {
        return $this->videosApi->getUserVideosCount($userId);
    });
}

Esto transforma un endpoint dependiente en uno más resiliente.

2. Fallbacks claros y amigables

Si un servicio remoto no responde, no siempre tiene sentido cortar la respuesta completa. Un fallback simple evita romper el ecosistema:

public function safeGetVideoCount(int $userId): int
{
    try {
        return $this->videosApi->getUserVideosCount($userId);
    } catch (\Throwable $e) {
        return 0; // “sin datos”, pero el endpoint de usuarios sigue funcionando
    }
}

En producción esto se puede acompañar con logging, alertas y circuit breakers simples.

3. Circuit Breaker liviano

Sin necesidad de librerías complejas, un patrón sencillo evita saturar un servicio caído:

public function getWithCircuitBreaker(int $userId): int
{
    if (cache()->has("videos-service-down")) {
        return 0;
    }

    try {
        return $this->videosApi->getUserVideosCount($userId);
    } catch (\Throwable $e) {
        cache()->put("videos-service-down", true, 60);
        return 0;
    }
}

Esto le da respiro al servicio remoto y estabiliza el comportamiento global.

4. Contratos estables

Si cambiás un endpoint remoto y afectás a otros equipos, replicaste el peor problema del monolito. Mantener contratos claros, versionados y estables es clave para que los microlitos no se vuelvan más rígidos que el monolito original.

En resumen, tener infraestructura separada es solo el primer paso. La clave para que los microlitos funcionen es que cada servicio pueda sobrevivir a la caída del otro y seguir entregando valor. La arquitectura mejora cuando los acoples dejan de ser de “vida o muerte” y pasan a ser dependencias manejables.