Etiqueta: redis

  • Capas invisibles de seguridad en PHP que bloquean ataques

    Capas invisibles de seguridad en PHP que bloquean ataques

    Resumen: las “capas invisibles” son defensas integradas en el runtime o en la capa infraestrutural que bloquean clases completas de ataques antes de que lleguen al negocio. Este artículo describe seis capas prácticas y muestra ejemplos de implementación en PHP.

    Introducción

    Los atacantes buscan huecos repetibles y fáciles: salidas sin escapar, sesiones que no cambian, consultas sin parámetros. Las capas invisibles obligan al runtime o a la infraestructura a aplicar defensas por defecto, reduciendo la carga mental del desarrollador y cerrando vectores comunes.

    Prerrequisitos

    Antes de integrar estas capas conviene contar con un entorno que permita soluciones como hashing moderno, plantillas con auto-escaping y mecanismos de almacenamiento para límites por IP.

    • PHP con soporte para Argon2id (mencionado en el texto base).
    • Motor de plantillas con auto-escaping (por ejemplo, Twig o Blade, o equivalente).
    • Acceso a la base de datos vía ORM o biblioteca que permita prepared statements.
    • Sistema de caché o store (Redis, memcached, etc.) para rate-limiting y rotación de tokens.

    Desarrollo

    Procedimiento

    Capa 1 — Auto-escaping a nivel de motor de plantillas: configure el motor para escapar por defecto las salidas. Así, incluso si un desarrollador olvida sanitizar una variable, el motor evita XSS a la salida.

    Capa 2 — Hashing memory-hard para credenciales: use algoritmos que consuman memoria (Argon2id o scrypt). Según el texto base, Argon2id es la opción recomendada para evitar que dumps de contraseñas sean fáciles de crackear.

    Capa 3 — Rotación automática de tokens: regenere identificadores de sesión en eventos críticos (login, elevación de privilegios) y mantenga un tiempo de validez corto para tokens expuestos.

    Capa 4 — Firewall de consultas dentro del ORM: haga que el acceso a la BD use solo consultas parametrizadas. Si el ORM obliga a parámetros, las inyecciones se eliminan en la práctica.

    Capa 5 — Middleware adaptativo a la tasa (rate-adaptive): aumente la latencia o limite intentos según patrones sospechosos. El objetivo es hacer el brute force económicamente inviable sin afectar a usuarios legítimos.

    Capa 6 — Content Security Policy (CSP): entregue cabeceras CSP estrictas para limitar fuentes de scripts, iframes y orígenes. Esto reduce el impacto de XSS y evita exfiltración desde el navegador.

    Ejemplos

    A continuación hay ejemplos concisos para poner en práctica las capas descritas.

    <?php
    // Hashing con Argon2id
    $password = 'usuario-password';
    $options = ['memory_cost' => 1<<17, 'time_cost' => 4, 'threads' => 2];
    $hash = password_hash($password, PASSWORD_ARGON2ID, $options);
    Lenguaje del código: PHP (php)

    Ejemplo de consultas parametrizadas con PDO (ORMs modernos aplican esto por defecto).

    <?php
    $stmt = $pdo->prepare('SELECT id, email FROM users WHERE email = :email');
    $stmt->execute([':email' => $email]);
    $user = $stmt->fetch();
    Lenguaje del código: PHP (php)

    Rotación de token/ID de sesión en eventos clave.

    <?php
    session_start();
    // Tras login o cambio de privilegios
    session_regenerate_id(true);
    $_SESSION['rotated_at'] = time();
    // Verificar caducidad en cada petición
    if (isset($_SESSION['rotated_at']) && time() - $_SESSION['rotated_at'] > 3600) {
        // forzar logout o revalidación
    }
    Lenguaje del código: PHP (php)

    Cabecera CSP mínima para reducir ejecución de scripts externos.

    <?php
    header("Content-Security-Policy: default-src 'self'; script-src 'self'");
    Lenguaje del código: PHP (php)

    Middleware simple para introducir fricción adaptativa en intentos de login.

    <?php
    $ip = $_SERVER['REMOTE_ADDR'];
    $attempts = $cache->get("login:{$ip}") ?? 0;
    if ($attempts > 5) {
        // añadir demora creciente (ej. usleep) para frustrar ataques automatizados
        usleep(min(500000 * ($attempts - 5), 2000000));
    }
    $cache->set("login:{$ip}", $attempts + 1, 300);
    Lenguaje del código: PHP (php)

    Checklist

    1. Habilitar auto-escaping en el motor de plantillas.
    2. Usar hashing memory-hard (Argon2id) para contraseñas.
    3. Forzar consultas parametrizadas desde el ORM o capa de datos.
    4. Implementar rotación de tokens y control de caducidad.
    5. Agregar middleware rate-adaptive para endpoints sensibles.
    6. Entregar cabeceras CSP estrictas y revisar políticas periódicamente.

    Conclusión

    Las capas invisibles eliminan vectores enteros de ataque al aplicar buenas prácticas desde el runtime y la infraestructura. Implementarlas reduce la superficie de ataque y permite a los equipos centrarse en la lógica de negocio con mayor confianza.

  • Trucos PHP para evitar picos de CPU en producción

    Trucos PHP para evitar picos de CPU en producción

    Este artículo resume tácticas prácticas y verificables para reducir picos de CPU en aplicaciones PHP en producción. Se centra en cambios puntuales: bucles, caché, extensiones y preload.

    Introducción

    Los picos de CPU suelen ser consecuencia de patrones repetitivos: bucles descontrolados, reconstrucciones de caché simultáneas, operaciones de cálculo en PHP y bloqueos que consumen ciclos. Aquí verás acciones concretas para reducir su impacto sin reescribir todo el stack.

    Prerrequisitos

    Antes de aplicar las tácticas: asegúrate de tener monitoreo de CPU y trazas, un sistema de caché (p. ej. Redis) y OPcache habilitado. Algunas recomendaciones asumen disponibilidad de extensiones (GMP/BCMath) o mecanismos de event loop si se migran procesos largos.

    opcache.enable=1
    opcache.preload=/var/www/preload.php
    Lenguaje del código: TOML, también INI (ini)

    Desarrollo

    Procedimiento

    A continuación se describen las tácticas principales, con ejemplos y recomendaciones de implementación mínima para reducir picos de CPU.

    1) Controlar bucles y procesamiento por lotes: no iteres colecciones potencialmente enormes en una sola pasada; procesa en chunks y paginación para limitar uso de CPU por iteración.

    <?php
    foreach ($users as $user) {
        process($user);
    }
    Lenguaje del código: PHP (php)
    <?php
    foreach (array_chunk($users, 500) as $batch) {
        foreach ($batch as $user) {
            process($user);
        }
    }
    Lenguaje del código: PHP (php)

    2) Caché: evita el “dogpile” (cache stampede) usando coalescencia de peticiones; solo un worker debe reconstruir el caché mientras los demás leen la versión existente.

    <?php
    if ($lock = $redis->setnx("lock:feed", 1)) {
        $redis->expire("lock:feed", 30);
        $data = buildFeed();
        $redis->set("cache:feed", $data, 300);
    } else {
        $data = $redis->get("cache:feed");
    }
    Lenguaje del código: PHP (php)

    3) Delegar cálculos pesados a extensiones o bibliotecas nativas. Para parsing/validación de JSON o aritmética de gran precisión, usar extensiones C (GMP, BCMath) reduce tiempo de CPU en PHP puro. El uso de funciones específicas (por ejemplo, json_validate() si está disponible) evita sobrecarga por manejo de excepciones.

    4) Evitar sleep() en workflows asíncronos. Reemplaza bucles con sleep por event loops (ReactPHP, Swoole) o por colas con workers que esperan con mecanismos eficientes.

    5) OPcache y preload: habilita OPcache y pre-carga clases/archivos críticos para reducir interpretación por petición y el coste del autoloader en caliente.

    <?php
    require_once __DIR__ . '/vendor/autoload.php';
    require_once __DIR__ . '/src/BigFatClass.php';
    Lenguaje del código: PHP (php)

    6) Detectar fugas ocultas de CPU: logging síncrono excesivo, regex con backtracking y operaciones I/O sin batching pueden generar picos. Prueba patrones costosos y usa loggers asíncronos o batch writers.

    Ejemplos

    Aquí hay ejemplos listos para adaptar a tus jobs o endpoints problemáticos.

    <?php
    // Antes: procesar todo en memoria (riesgo de pico)
    foreach ($users as $user) {
        process($user);
    }
    Lenguaje del código: PHP (php)
    <?php
    // Después: procesar por lotes para limitar CPU por iteración
    foreach (array_chunk($users, 500) as $batch) {
        foreach ($batch as $user) {
            process($user);
        }
    }
    Lenguaje del código: PHP (php)
    <?php
    // Coalescencia de caché en Redis
    if ($lock = $redis->setnx("lock:feed", 1)) {
        $redis->expire("lock:feed", 30);
        $data = buildFeed();
        $redis->set("cache:feed", $data, 300);
    } else {
        $data = $redis->get("cache:feed");
    }
    Lenguaje del código: PHP (php)

    Checklist

    1. Identificar endpoints/jobs con mayor CPU y trazar hot paths.
    2. Reescribir bucles para procesamiento por lotes o paginación.
    3. Implementar coalescencia de caché (lock + fallback) para evitar stampedes.
    4. Delegar cómputo pesado a extensiones nativas cuando sea posible.
    5. Habilitar OPcache y preload para reducir interpretación y autoload en cada petición.
    6. Sustituir sleep() por event loops o colas con espera eficiente.

    Conclusión

    Los picos de CPU se solucionan con disciplina operativa y correcciones puntuales: controlar bucles, proteger la caché, delegar trabajo pesado y optimizar la carga de código. Implanta las medidas gradualmente y valida con métricas.

    Pequeñas correcciones en el código y la configuración suelen eliminar los picos de CPU más rápido que reescribir todo el sistema.

  • Notificaciones PHP en tiempo real con Redis y WebSockets

    Notificaciones PHP en tiempo real con Redis y WebSockets

    Resumen: guía práctica para enviar notificaciones en tiempo real desde PHP usando Redis como bus de mensajes y WebSockets para entrega instantánea. Incluye ejemplo mínimo, buenas prácticas y checklist de despliegue.

    Introducción

    Las notificaciones en tiempo real son fundamentales para la experiencia de usuario moderna. En vez de pollings periódicos, una combinación de Redis (Pub/Sub o Streams) y un servidor WebSocket permite entregar mensajes al instante desde PHP.

    Prerrequisitos

    • PHP con soporte para ejecución de procesos permanentes (p. ej. Workerman, Swoole o Ratchet)
    • Redis (instancia accesible desde el servidor WebSocket)
    • Cliente Redis para PHP (Predis o phpredis) y composer
    • Clientes Web que soporten WebSockets y lógica de reconexión

    Desarrollo

    La arquitectura básica separa responsabilidades: la aplicación PHP publicará eventos en Redis; un proceso WebSocket suscrito a Redis retransmitirá esos mensajes a los clientes conectados.

    Procedimiento

    Pasos esenciales:

    1. Publicar un evento en Redis desde la app PHP cuando ocurre la acción (por ejemplo, comentario nuevo).
    2. El proceso WebSocket está suscrito al canal Redis y recibe el evento.
    3. El proceso WebSocket envía el payload a los clientes conectados (filtrando por usuario o canal si aplica).
    4. El cliente maneja el mensaje (mostrar notificación, solicitar detalles, marcar como leído, etc.).

    Ejemplo mínimo de servidor WebSocket en PHP usando Workerman y Predis (suscripción a Redis y broadcast a conexiones activas).

    <?php
    use Workerman\Worker;
    use Predis\Client as RedisClient;
    
    require 'vendor/autoload.php';
    
    $ws = new Worker("websocket://0.0.0.0:8080");
    $ws->count = 1;
    
    $redis = new RedisClient();
    
    $ws->onWorkerStart = function() use ($ws, $redis) {
        $pubsub = $redis->pubSubLoop();
        $pubsub->subscribe('notifications');
        foreach ($pubsub as $message) {
            if ($message->kind === 'message') {
                foreach ($ws->connections as $connection) {
                    $connection->send($message->payload);
                }
            }
        }
    };
    
    Worker::runAll();
    Lenguaje del código: PHP (php)

    Este proceso mantiene una conexión permanente a Redis y distribuye cada mensaje recibido a todas las conexiones WebSocket. En producción conviene no enviar todo el payload a todos los clientes: filtrar por canal/usuario.

    Ejemplo de publicación de un evento desde la aplicación PHP usando Predis.

    <?php
    use Predis\Client as RedisClient;
    
    $redis = new RedisClient();
    
    $event = json_encode([
        'type' => 'comment_created',
        'user_id' => 42,
        'data' => ['id' => 123, 'excerpt' => 'Nuevo comentario']
    ]);
    
    $redis->publish('notifications', $event);
    Lenguaje del código: PHP (php)

    En el ejemplo anterior publicamos en un canal genérico ‘notifications’. Para evitar sobre-broadcasting, use canales por usuario o por topic (p. ej. notifications:user:42).

    Ejemplos

    Cliente JavaScript: conexión WebSocket básica con reconexión y manejo de mensajes ligeros (solo resumen; adapte según su app).

    function createSocket(url) {
      let ws;
      let retry = 1000;
    
      function connect() {
        ws = new WebSocket(url);
    
        ws.onopen = () => {
          retry = 1000; // reset backoff
          console.log('WS connected');
        };
    
        ws.onmessage = (ev) => {
          const msg = JSON.parse(ev.data);
          // manejar evento: mostrar notificación o solicitar detalles
          console.log('evento', msg);
        };
    
        ws.onclose = () => {
          console.log('WS closed, reconnecting in', retry);
          setTimeout(connect, retry);
          retry = Math.min(30000, retry * 2);
        };
    
        ws.onerror = (err) => {
          console.error('WS error', err);
          ws.close();
        };
      }
    
      connect();
      return () => ws && ws.close();
    }
    
    // uso
    const stop = createSocket('wss://example.com:8080');
    Lenguaje del código: JavaScript (javascript)

    Consejo: mantenga los payloads ligeros. Enviar solo el ID del evento o un resumen reduce latencia y consumo de ancho de banda.

    Redis + WebSockets transforman un backend PHP tradicional en un canal de notificaciones cercano a tiempo real, sin necesidad de reescrituras completas.

    Checklist

    1. Usar canales por usuario o topic para evitar sobre-broadcast.
    2. Autenticar y autorizar suscripciones (gateway o tokens JWT).
    3. Implementar reconexión y reintentos en cliente.
    4. Considerar Redis Streams si necesita persistencia y replay de mensajes.
    5. Monitoreo del proceso WebSocket y alertas para reinicio automático.
    6. Limitar tamaño del payload y evitar enviar datos sensibles por el socket.

    Conclusión

    Combinar Redis y WebSockets permite a aplicaciones PHP ofrecer notificaciones instantáneas sin depender de polling. El patrón reduce latencia y escala bien si se aplica filtrado por canales, autenticación y manejo de fallos.

    Empiece con un prototipo mínimo (un proceso WebSocket suscrito a Redis) y evolucione a Streams, balanceo y autenticación según las necesidades de producción.

  • Laravel a escala: 5 trucos para consultar millones de registros

    Laravel a escala: 5 trucos para consultar millones de registros

    Este artículo resume cinco técnicas prácticas para consultar millones de filas en Laravel sin agotar memoria ni tiempo CPU. Cada técnica incluye una explicación breve y ejemplos de código listos para usar.

    Aplica estas prácticas en procesos de reporting, ETL o consultas masivas para mantener tiempos de respuesta y uso de recursos controlados.

    Introducción

    En consultas a tablas masivas, prácticas comunes como SELECT * o cargar todo con get() provocan consumo excesivo de RAM y CPU. Las siguientes cinco estrategias reducen uso de recursos y aceleran procesos.

    Prerrequisitos

    Antes de aplicar las técnicas: asegúrate de contar con un esquema de base de datos razonable y mecanismos de cacheo/colas si vas a usar preagregados o jobs en segundo plano.

    • Acceso al código de tus modelos/Eloquent.
    • Permiso para crear índices y migraciones en la base de datos.
    • Un sistema de cache (Redis, Memcached) y, si procede, soporte para jobs/colas.

    Desarrollo

    Procedimiento

    A continuación se presentan las cinco técnicas: seleccionar columnas esenciales, procesar por chunks o stream, indexar y optimizar WHERE, preagregar datos y cachear resultados pesados.

    1. Seleccionar sólo las columnas esenciales

    Evita SELECT * cuando sólo necesitas unas pocas columnas. Reducir columnas reduce CPU, memoria y ancho de banda.

    <?php
    // ❌ Evitar: carga todas las columnas
    $orders = Order::all();
    
    // ✅ Seleccionar sólo lo necesario
    $orders = Order::select('id', 'amount', 'created_at')
        ->whereBetween('created_at', [$start, $end])
        ->get();
    Lenguaje del código: PHP (php)

    En el ejemplo base, reducir de 20 columnas a 3 puede bajar el consumo de memoria de ~1.2 GB a ~200 MB en un conjunto grande de filas.

    2. Procesar por chunks o con cursor (stream)

    No uses get() para millones de filas. chunk() y cursor() procesan en partes y mantienen baja la memoria.

    <?php
    // Procesar en bloques de 10.000
    Order::where('status', 'completed')
        ->select('id', 'amount')
        ->chunk(10000, function ($orders) {
            foreach ($orders as $order) {
                // generar fila de reporte
            }
        });
    
    // O procesar con cursor para stream perezoso
    $orders = Order::cursor()->filter(fn ($order) => $order->amount > 1000);
    Lenguaje del código: PHP (php)

    En pruebas citadas, procesar 5M de filas con cursor/chunks reduce consumo de memoria a decenas de MB frente a cientos o más.

    3. Índices y cláusulas WHERE eficientes

    Filtros y ordenamientos sin índices provocan full table scans. Indexa columnas usadas en WHERE, JOIN y ORDER BY y evita patrones ineficientes como LIKE ‘%…%’.

    <?php
    // Ejemplo de migración para agregar índices
    Schema::table('orders', function (Blueprint $table) {
        $table->index('status');
        $table->index('created_at');
    });
    Lenguaje del código: PHP (php)

    Un ejemplo reportado mostró una reducción de tiempo de consulta de 120 s a 0.8 s tras indexar columnas utilizadas en filtros.

    4. Preagregar datos para reportes pesados

    Evita agrupar o sumar decenas de millones de filas en tiempo real. Precalcula resúmenes con jobs nocturnos o usa vistas/materialized views si la BD lo permite.

    <?php
    class GenerateOrderSummary implements ShouldQueue {
        public function handle() {
            $summary = Order::selectRaw('
                DATE(created_at) AS date,
                COUNT(*) AS total_orders,
                SUM(amount) AS revenue
            ')
            ->whereDate('created_at', today()->subDay())
            ->groupBy('date')
            ->first();
    
            Report::updateOrCreate(['date' => $summary->date], (array)$summary);
        }
    }
    Lenguaje del código: PHP (php)

    Con preagregados, la carga de un reporte puede pasar de minutos a decenas de milisegundos; en el ejemplo base, un reporte cargó en ~50 ms.

    5. Cachear consultas costosas

    Para consultas repetidas, guarda el resultado en cache con expiración y/o tags. Invalida o refresca la cache cuando los datos subyacentes cambien.

    <?php
    $report = Cache::remember("daily_sales_report:{$date}", 3600, fn() =>
        Order::whereDate('created_at', $date)
            ->selectRaw('COUNT(*) AS orders, SUM(amount) AS revenue')
            ->first()
    );
    Lenguaje del código: PHP (php)

    Usa Redis o Memcached según tu infraestructura y define políticas claras de invalidación para evitar datos obsoletos.

    Ejemplos

    Ejemplos concretos ya mostrados: selección de columnas, chunk/cursor, migración para índices, job para preagregados y cacheo con Cache::remember.

    Adapta los tamaños de chunk y la expiración del cache a la carga real y al patrón de acceso de tu sistema.

    Checklist

    1. Revisar consultas y eliminar SELECT *.
    2. Usar chunk() o cursor() para procesado masivo.
    3. Indexar columnas usadas en WHERE, JOIN y ORDER BY.
    4. Preagregar resultados pesados con jobs o vistas.
    5. Cachear consultas repetidas y definir estrategia de invalidación.

    Conclusión

    Combinando selección precisa de columnas, procesamiento por partes, buenos índices, preagregados y cacheo, puedes consultar millones de registros en Laravel con uso de recursos razonable y tiempos de respuesta aceptables.

    Empieza por los cambios menos invasivos (select, chunk, cache) y mide impacto antes de introducir cambios más estructurales como materialized views o rediseño de esquemas.

  • Evolución de las colas en Laravel: workers, deferred y background

    Evolución de las colas en Laravel: workers, deferred y background

    Este artículo resume la evolución del sistema de colas en Laravel: desde los workers tradicionales hasta el driver background basado en concurrencia. Explica usos, diferencias y ejemplos prácticos de implementación.

    Introducción

    Laravel ha transitado de un sistema de colas basado en workers persistentes a opciones que reducen la complejidad operativa: drivers deferred y background (impulsado por concurrencia).

    Prerrequisitos

    Antes de aplicar cualquiera de las estrategias descritas, confirma lo siguiente:

    • Proyecto Laravel con entorno PHP configurado.
    • Driver de colas definido (Redis, database, etc.) si planeas usar workers tradicionales.
    • En caso de background driver, la configuración de conexiones en config/queue.php debe incluir la conexión ‘background’ (ver ejemplo).

    Desarrollo

    Procedimiento

    A continuación se describen las tres aproximaciones principales y cómo elegir entre ellas según la carga y la tolerancia a fallos.

    1. Workers tradicionales: ejecutan jobs mediante procesos persistentes (p. ej. php artisan queue:work redis), adecuados para cargas pesadas y con control avanzado de reintentos y fallos.
    2. Driver deferred: ejecuta el job después de enviar la respuesta HTTP, sin worker. Adecuado para tareas ligeras y no críticas.
    3. Driver background (concurrencia): ejecuta jobs en procesos PHP separados, sin worker persistente; equilibrio entre robustez y simplicidad operativa.

    Ventajas y limitaciones resumidas:

    • Workers tradicionales: alto rendimiento y control; requieren DevOps para gestionar procesos.
    • Deferred: baja sobrecarga; limitado en reintentos y duración de tarea.
    • Background: sin workers dedicados, más robusto que deferred; útil para tareas de duración media.
    php artisan queue:work redis
    Lenguaje del código: Bash (bash)
    <?php
    return [
        'connections' => [
            'background' => [
                'driver' => 'background',
            ],
        ],
    ];
    Lenguaje del código: PHP (php)

    El ejemplo anterior muestra cómo declarar una conexión ‘background’ en config/queue.php. Su dispatch usa la conexión para ejecutar el job en otro proceso PHP.

    Ejemplos

    Ejemplo de clase Job que implementa ShouldQueue y se serializa para su ejecución en background o por un worker.

    <?php
    namespace App\Jobs;
    
    use Illuminate\Bus\Queueable;
    use Illuminate\Contracts\Queue\ShouldQueue;
    use Illuminate\Foundation\Bus\Dispatchable;
    use Illuminate\Queue\SerializesModels;
    
    class RecordDelivery implements ShouldQueue
    {
        use Dispatchable, Queueable, SerializesModels;
    
        public function __construct(public $order)
        {
        }
    
        public function handle()
        {
            // lógica de procesamiento
        }
    }
    Lenguaje del código: PHP (php)

    Dispatch desde un controlador usando la conexión background para evitar bloquear la petición HTTP.

    <?php
    use App\Jobs\RecordDelivery;
    
    class DeliveryController
    {
        public function store(Request $request)
        {
            $order = Order::create([...]);
            RecordDelivery::dispatch($order)->onConnection('background');
    
            return response()->json(['status' => 'processing'], 202);
        }
    }
    Lenguaje del código: PHP (php)

    Checklist

    1. Determina la criticidad de la tarea (alta → worker tradicional).
    2. Si la tarea es ligera y no crítica, considera deferred.
    3. Para equilibrio operativo (sin workers pero más robusto que deferred), usa el driver background.
    4. Configura reintentos, timeouts y monitoreo según el método elegido.

    Conclusión

    La evolución de las colas en Laravel ofrece alternativas para distintos perfiles de carga operativa. Elegir entre workers, deferred o background depende de la carga, la tolerancia a fallos y la capacidad operativa del equipo.

    Si buscas simplificar la operación sin renunciar a capacidad de procesamiento, el driver background —impulsado por concurrencia— es una opción intermedia interesante.

  • Registrar cada llamada API sin ralentizar el servidor

    Registrar cada llamada API sin ralentizar el servidor

    Resumen: Cómo registrar cada llamada a tu API sin degradar el rendimiento. Enfoque práctico: logging asíncrono, buffering, offload a workers, enmascarado de datos y rotación.

    Introducción

    Registrar cada petición API es crítico para depuración, auditoría y análisis, pero hacerlo mal puede convertir el logging en el principal cuello de botella.

    La regla de oro: nunca hagas que el manejador principal espere a que los logs se escriban. El registro debe ser asíncrono y, preferiblemente, salir del camino de ejecución principal.

    Prerrequisitos

    Los ejemplos usan Node.js y bibliotecas comunes; adapta las ideas a otros runtimes si es necesario.

    • Dependencia de un logger de alto rendimiento (p. ej. Pino).
    • Mecanismo para buffering o una cola (memoria, Redis, Kafka).
    • Worker o servicio externo para persistencia y envío a sistemas centralizados.

    Desarrollo

    Procedimiento

    Paso 1 — Decide qué registrar: evita sobre-logging. Campos típicos: timestamp, método, ruta, status, latencia, IP, userId, requestId y payload con datos sensibles enmascarados.

    {
      "time": "2025-08-11T14:23:45.123Z",
      "method": "POST",
      "url": "/api/orders",
      "status": 201,
      "responseTimeMs": 123,
      "userId": "usr_1a2b3c",
      "ip": "203.0.113.42",
      "userAgent": "Mozilla/5.0 (Macintosh...)",
      "requestId": "req_abcd1234"
    }
    Lenguaje del código: JSON / JSON con comentarios (json)

    Paso 2 — Usa un logger no bloqueante. Olvida console.log en producción; emplea un logger diseñado para escritura asíncrona y serialización rápida.

    const pino = require('pino');
    const logger = pino({
      level: 'info',
      transport: {
        target: 'pino-pretty'
      }
    });
    
    app.use((req, res, next) => {
      const start = Date.now();
      
      res.on('finish', () => {
        logger.info({
          method: req.method,
          url: req.originalUrl,
          status: res.statusCode,
          responseTime: Date.now() - start
        });
      });
      
      next();
    });
    Lenguaje del código: JavaScript (javascript)

    Paso 3 — Bufferiza en memoria y envía en lotes. Convierte miles de escrituras pequeñas en pocas escrituras grandes.

    let logBuffer = [];
    const BUFFER_SIZE = 50;
    const FLUSH_INTERVAL = 5000; // ms
    
    function flushLogs() {
      if (logBuffer.length > 0) {
        logger.info({ batch: logBuffer });
        logBuffer = [];
      }
    }
    
    setInterval(flushLogs, FLUSH_INTERVAL);
    
    app.use((req, res, next) => {
      const start = Date.now();
    
      res.on('finish', () => {
        logBuffer.push({
          method: req.method,
          url: req.originalUrl,
          status: res.statusCode,
          time: Date.now(),
          latency: Date.now() - start
        });
    
        if (logBuffer.length >= BUFFER_SIZE) {
          flushLogs();
        }
      });
    
      next();
    });
    Lenguaje del código: JavaScript (javascript)

    Paso 4 — Desacopla mediante cola y workers: para tráfico intenso, envía logs a una cola y procesa desde procesos independientes.

    const Redis = require('ioredis');
    const pub = new Redis();
    
    app.use((req, res, next) => {
      const start = Date.now();
    
      res.on('finish', () => {
        pub.publish('api_logs', JSON.stringify({
          method: req.method,
          url: req.originalUrl,
          status: res.statusCode,
          latency: Date.now() - start
        }));
      });
    
      next();
    });
    Lenguaje del código: JavaScript (javascript)
    const sub = new Redis();
    sub.subscribe('api_logs');
    sub.on('message', (channel, message) => {
      const logData = JSON.parse(message);
      // Persistir logData de forma asíncrona (BD, ELK, S3...)
    });
    Lenguaje del código: JavaScript (javascript)

    Paso 5 — Envío remoto asíncrono: si mandas logs a sistemas como ELK o CloudWatch, hazlo en lotes o por workers para evitar latencia en el request path.

    const winston = require('winston');
    require('winston-cloudwatch');
    
    winston.add(new winston.transports.CloudWatch({
      logGroupName: 'my-api-logs',
      logStreamName: 'production',
      awsRegion: 'us-east-1',
      jsonMessage: true
    }));
    
    app.use((req, res, next) => {
      const start = Date.now();
      res.on('finish', () => {
        winston.info({
          method: req.method,
          url: req.originalUrl,
          status: res.statusCode,
          latency: Date.now() - start
        });
      });
      next();
    });
    Lenguaje del código: JavaScript (javascript)

    Paso 6 — Enmascara datos sensibles antes de loguear: nunca escribas contraseñas, números de tarjeta o tokens sin protección.

    function maskSensitive(obj) {
      const clone = { ...obj };
      if (clone.password) clone.password = '******';
      if (clone.cardNumber) clone.cardNumber = '**** **** **** ' + clone.cardNumber.slice(-4);
      return clone;
    }
    
    app.use(express.json());
    app.use((req, res, next) => {
      req.body = maskSensitive(req.body);
      next();
    });
    Lenguaje del código: JavaScript (javascript)

    Paso 7 — Mide y ajusta: compara latencias y uso de CPU/memoria antes y después del cambio. Usa herramientas de carga y APM para validar impacto.

    autocannon -c 100 -d 30 http://localhost:3000
    Lenguaje del código: Bash (bash)

    Paso 8 — Rotación y archivo: configura rotación por tamaño o día y mueve logs antiguos a almacenamiento económico.

    pino server.js | tee >(pino-pretty) | rotatelogs ./logs/api-%Y-%m-%d.log 86400
    Lenguaje del código: Bash (bash)

    Paso 9 — Distribuye a gran escala: evita escribir localmente, usa shippers (Filebeat/Fluent Bit), Kafka para ingesta masiva y sampling para reducir volumen de success logs.

    Paso 10 — Arquitectura de producción (resumen): gateway → collectors/colas → workers → almacenamiento indexable → dashboards y alertas.

    Ejemplos

    Los ejemplos anteriores cubren patrones comunes: logger rápido (Pino), buffering en proceso, publicación a Redis y consumo por workers, y envío asíncrono a servicios remotos.

    Checklist

    1. No bloquear el request path: logging asíncrono.
    2. Usar un logger de alto rendimiento (p. ej. Pino).
    3. Bufferizar y enviar en lotes.
    4. Offload a workers o colas para tráfico intenso.
    5. Enmascarar datos sensibles antes de persistir.
    6. Rotación y archivado de logs.
    7. Medir impacto y ajustar frecuencias/ tamaños de lote.

    Conclusión

    Registrar cada llamada API es viable si se diseña para no bloquear el flujo principal: emplea loggers rápidos, buffering, colas y workers; enmascara datos; y monitoriza el costo del logging.

    Aplica estas prácticas progresivamente y verifica con pruebas de carga y APM antes de desplegar en producción.