--- title: 'Diseño de sistemas de ingesta de eventos de alta carga | DevSense' description: 'Cómo manejar miles de eventos HTTP entrantes por segundo: validación perimetral (edge), capas de almacenamiento en búfer, escritura por lotes en el almacenamiento y cómo evitar el agotamiento de conexiones a la base de datos bajo picos de carga.' faq: - { question: '¿Por qué se deben evitar las escrituras síncronas en la base de datos dentro del endpoint de ingesta?', answer: 'Las bases de datos relacionales están diseñadas para la consistencia transaccional compatible con ACID y funcionan mal bajo ráfagas de escritura altamente concurrentes y de corta duración. Las escrituras síncronas en la base de datos crean bloqueos de tablas, agotamiento de conexiones y cuellos de botella en la E/S de disco. Descargar las escrituras en una cola secuencial rápida o en un agente basado en logs (como Kafka o Redis Streams) desacopla la velocidad de ingesta de los límites de almacenamiento de la base de datos.' } - { question: '¿Cuál es el beneficio de usar una API Gateway con límite de tasa (rate limiting) en el perímetro de la ingesta?', answer: 'Una API Gateway bloquea las solicitudes no válidas o abusivas (DDoS, JSON malformado, fallas de autenticación) antes de que lleguen a la capa de aplicación. Esto protege a los servidores internos y a los agentes de mensajería descendentes del agotamiento de recursos y mantiene la disponibilidad del servicio durante los picos de carga.' } - { question: '¿Cómo ayuda el agrupamiento por lotes del lado del cliente (client-side batching) a los sistemas de ingesta de eventos?', answer: 'El agrupamiento por lotes del lado del cliente agrupa múltiples registros de eventos pequeños en una sola carga útil de solicitud HTTP. Esto reduce drásticamente la sobrecarga de negociación de red, los costos de serialización HTTP y la cantidad de conexiones en los servidores de ingesta, lo que permite que el sistema ingiera millones de eventos con una fracción de las solicitudes brutas.' } - { question: '¿Qué es backpressure (contrapresión) y por qué es importante en las arquitecturas de ingesta?', answer: 'La contrapresión es un mecanismo en el que los consumidores descendentes señalan a los servicios de ingesta ascendentes que ralenticen o almacenen en búfer el tráfico entrante cuando la velocidad de procesamiento no puede mantener el ritmo de la tasa de ingesta. Sin contrapresión, los servicios descendentes (como los nodos de trabajo o las bases de datos) se sobrecargan, se quedan sin memoria o fallan.' } published: '2026-05-31' --- # Diseñar sistemas de ingesta de eventos de alta carga: búferes, lotes y límites Crear un endpoint que acepte un webhook web o un evento de seguimiento es simple. Crear uno que se mantenga rápido, rentable y disponible cuando diez mil aplicaciones móviles envían cargas útiles analíticas **en el mismo segundo** es un problema diferente. Bajo carga, una ruta ingenua de \"recibir, validar, escribir en SQL\" se colapsa: las conexiones a la base de datos se agotan, la E/S de disco se dispara y los procesos de trabajo web se acumulan en cola hasta que el balanceador de carga corta el tráfico. La ingesta de eventos robusta consiste en **aceptar bytes rápidamente**, **almacenarlos en búfer de inmediato** y **escribirlos en lotes** a una velocidad que la capa de almacenamiento realmente disfrute. **Guías relacionadas:** [Message queues compared](message-queues-compared) · [Databases under load](database-performance-and-scaling) · [Observability and monitoring](observability-monitoring-laravel) ## Índice * [La anatomía del cuello de botella](#bottleneck) * [Arquitectura: Desacoplar la recepción de la escritura](#architecture) * [El endpoint de ingesta: ligero y sin estado](#endpoint) * [Enrutamiento perimetral y validación de la API Gateway](#edge) * [Capa de almacenamiento en búfer: Redis Streams, Kafka o registros en disco](#buffering) * [Procesamiento por lotes y trabajadores](#batching) * [Manejo de picos: contrapresión y descarte](#spikes) * [Errores comunes](#common-mistakes) * [Lista de verificación](#checklist) * [Cuestionario de autoevaluación](#self-test-quiz) --- ## La anatomía del cuello de botella Cuando los eventos de alta frecuencia golpean una pila estándar: * **Sobrecarga HTTP** — Negociar TLS, analizar encabezados e inicializar el framework por solicitud consume CPU. * **Llamadas síncronas de almacenamiento** — Si el endpoint espera a que termine `INSERT INTO ...`, la conexión del cliente permanece abierta. Esto retiene la memoria y los procesos secundarios FPM. * **E/S de disco y contención de bloqueos** — Cada escritura individual obliga a la base de datos a escribir en su registro de escritura anticipada (WAL) y sincronizar con el disco. Cien escrituras paralelas provocan cien escrituras de disco; un lote de mil provoca solo una. --- ## Arquitectura: Desacoplar la recepción de la escritura El principio de diseño central es la **asincronía**: ``` [ Client ] ──(HTTP POST)──> [ Ingestion Gateway ] │ (Push to Buffer) ▼ [ Buffer Tier ] (Redis/Kafka) ▲ (Batch Read) │ [ Worker Pool ] │ (Bulk Write) ▼ [ Storage Layer ] (ClickHouse/DB) ``` 1. **Ingestion Gateway** recibe la solicitud, realiza la validación del esquema, la envía al búfer y devuelve un `202 Accepted` de inmediato. 2. **Buffer Tier** (cola de memoria duradera o log de confirmaciones) retiene los eventos sin procesar. 3. **Worker Pool** lee los eventos del búfer en lotes y los escribe en el almacenamiento. --- ## El endpoint de ingesta: ligero y sin estado El código que maneja la solicitud entrante debe hacer lo mínimo indispensable: ```php // app/Http/Controllers/IngestController.php public function __invoke(IngestRequest $request) { // 1. Validación ligera (solo coincidencia de esquema) $payload = $request->validated(); // 2. Enviar al búfer (por ejemplo, Redis Stream o Kafka) $this->buffer->push('events', [ 'event_id' => Str::uuid()->toString(), 'received_at' => now()->getTimestamp(), 'data' => json_encode($payload), ]); // 3. Devolver confirmación inmediata return response()->json(['status' => 'accepted'], 202); } ``` Mantén la huella de FPM pequeña: evita llamar a APIs externas, ejecutar consultas complejas de bases de datos o realizar procesamientos de imágenes pesados en la CPU en esta ruta de solicitud. --- ## Enrutamiento perimetral y validación de la API Gateway Filtra las solicitudes incorrectas antes de que lleguen a los trabajadores de la aplicación: * **API Gateway (Nginx, Kong, AWS API Gateway)** — Valida las claves de API, aplica límites de tasa y bloquea las cargas útiles mal formadas. * **Validación de carga útil** — Utiliza la validación de esquemas JSON a nivel de gateway si es posible, reduciendo la sobrecarga de análisis de la aplicación. * **Redirección y CDN** — Para píxeles de seguimiento estáticos (rutas GET), devuelve la imagen del píxel desde el borde de la CDN, enviando los volcados de logs de forma asíncrona al almacenamiento. --- ## Capa de almacenamiento en búfer: Redis Streams, Kafka o registros en disco Elige tu búfer en función de las garantías de datos y el volumen: | Búfer | Rendimiento máximo | Complejidad operativa | Nota | |-------|--------------------|-----------------------|------| | **Redis Streams** | Muy alto | Baja | Excelente para colas limitadas por memoria. Monitorea el tamaño de la memoria. | | **Apache Kafka** | Extremo | Alta | Estándar para flujos de eventos distribuidos. Durable en disco. | | **AWS Kinesis / GCP PubSub** | Alto | Baja (Gestionado) | Pago por uso, escala automáticamente, dependencia del proveedor. | > [!NOTE] > **Asignación de memoria** > Si tu búfer se ejecuta en memoria (como Redis), monitorea de cerca el uso de la memoria. Si los consumidores descendentes se ralentizan, la cola consumirá la RAM y colapsará el servidor. --- ## Procesamiento por lotes y trabajadores Escribir eventos uno por uno es el asesino más común del rendimiento de las bases de datos. Los trabajadores deben leer en lotes: ```php // app/Console/Commands/ProcessBufferBatch.php public function handle() { // Leer hasta 1000 eventos del flujo $events = $this->buffer->readBatch('events', 1000); if (empty($events)) { return; } // Transformar y escribir en una sola consulta masiva (bulk) $this->storage->bulkInsert( $this->transform($events) ); // Confirmar los offsets procesados $this->buffer->acknowledge('events', collect($events)->pluck('id')); } ``` Para grandes cargas de trabajo analíticas, considera bases de datos orientadas a columnas como **ClickHouse**, **Snowflake** o **AWS Redshift**, que están diseñadas para inserciones masivas de alta velocidad. --- ## Manejo de picos: contrapresión y descarte Cuando la carga supera la capacidad del sistema: * **Contrapresión (Backpressure)** — Los trabajadores descendentes indican a la gateway de ingesta que ralentice las solicitudes entrantes o las ponga en cola en el perímetro. * **Descarte de carga (Load Shedding)** — Bloquea el tráfico de baja prioridad en la gateway, devolviendo `429 Too Many Requests` para preservar la disponibilidad del servicio principal. * **Disyuntores (Circuit Breakers)** — Si la base de datos o el agente de la cola fallan, abre el disyuntor para fallar rápido en lugar de colgar los hilos de conexión. --- ## Errores comunes 1. **Escrituras síncronas en la base de datos**: Escribir eventos directamente en la base de datos de la aplicación dentro del ciclo de vida de la solicitud HTTP. 2. **Falta de límites de tasa de ingesta**: Permitir que un solo cliente o un bucle defectuoso de una aplicación móvil sature el endpoint de ingesta. 3. **Comprobaciones de autenticación pesadas**: Consultar la base de datos para comprobar el estado del cliente en cada solicitud de evento en la ruta rápida. En su lugar, usa tokens de API respaldados por caché. 4. **No monitorear el retraso del búfer (Buffer Lag)**: Hacer seguimiento solo de la salud de la aplicación mientras la cola del búfer de eventos crece sin control en segundo plano. --- ## Lista de verificación 1. **Endpoint sin estado:** ¿El controlador devuelve una respuesta sin tocar el almacenamiento persistente? 2. **Almacenamiento en búfer:** ¿Existe una capa de cola entre la ingesta y el almacenamiento? 3. **Validación perimetral:** ¿Se bloquean los esquemas no válidos y las llamadas no autorizadas a nivel de la gateway? 4. **Escritura por lotes:** ¿Los hilos de los trabajadores combinan registros en inserciones masivas? 5. **Plan de contrapresión:** ¿El sistema descarta la carga o restringe el tráfico cuando las colas se llenan? --- ## Resumen La ingesta a escala consiste en separar la **aceptación del evento** del **almacenamiento del evento**. Concéntrate en mantener la puerta principal rápida y simple, mientras usas un búfer fuerte para alimentar el backend a un ritmo constante y manejable. --- ## Cuestionario de autoevaluación ### Pregunta 1: ¿Cuál es el beneficio principal de devolver un código de respuesta `202 Accepted` en una API de ingesta? - A) Formatea la carga útil de la respuesta en JSON comprimido. - B) Informa al cliente que la carga útil fue recibida y puesta en cola, lo que permite que el hilo HTTP se cierre sin esperar al almacenamiento en la base de datos. - C) Garantiza que el evento esté libre de errores de esquema.
Mostrar respuestas **Respuesta: B** Una respuesta `202 Accepted` indica que la solicitud ha sido aceptada para su procesamiento, pero el procesamiento no se ha completado. Esto permite que la conexión finalice de inmediato, manteniendo al mínimo la duración de la solicitud y el uso de recursos.
--- ### Pregunta 2: ¿Por qué las bases de datos analíticas como ClickHouse requieren inserciones por lotes (por ejemplo, 10,000 filas a la vez) en lugar de inserciones de filas individuales? - A) Las inserciones individuales eluden los controles de seguridad. - B) Los motores columnares escriben datos en partes físicas grandes y comprimidas en el disco; escribir fila por fila crea demasiados archivos pequeños, agotando la E/S de disco. - C) El agrupamiento evita fugas de memoria en los trabajadores de PHP.
Mostrar respuestas **Respuesta: B** Los modelos de almacenamiento columnar están optimizados para escrituras de bloques secuenciales. Escribir filas individuales obliga al motor a fusionar repetidamente partes pequeñas en el disco, lo que provoca la amplificación de la escritura y la saturación del disco.