Escalando una Plataforma de Detección de Amenazas en Tiempo Real 10x

Envadel proporcionó 4 ingenieros senior bajo el modelo de Staff Augmentation. Cada ingeniero se integró directamente en uno de los squads existentes del cliente, participando en sus standups, usando sus herramientas (GitLab, Linear, Slack) y siguiendo sus procesos de code review. Los ingenieros augmented se enfocaron en la iniciativa de escalabilidad de la plataforma mientras los ingenieros del cliente continuaban con el desarrollo de funcionalidades.

El enfoque técnico implicó descomponer el motor de detección monolítico en microservicios event-driven en Go, reemplazar el procesador de eventos single-threaded con un pipeline de streaming basado en Kafka, e implementar Kubernetes Horizontal Pod Autoscaler (HPA) para escalado elástico. La migración se ejecutó de forma incremental, con tráfico gradualmente transferido del motor antiguo al nuevo pipeline usando feature flags.

Un workstream paralelo se enfocó en el pipeline de threat scoring basado en ML. Los modelos ML existentes en Python se re-desplegaron como servicios de inferencia optimizados con capacidades de predicción por lotes, reduciendo el coste de cómputo por predicción en un 75% manteniendo la precisión del modelo. Se desplegó un nuevo stack de observabilidad Grafana/Prometheus para proporcionar visibilidad en tiempo real de la latencia de detección, throughput y tasas de falsos positivos.

El motor de detección core se reescribió en Go, elegido por su modelo de concurrencia superior (goroutines), bajo consumo de memoria y comportamiento predecible de recolección de basura — requisitos críticos para garantías de procesamiento inferior al segundo. Cada categoría de regla de detección (anomalía de red, comportamiento de endpoint, eventos de autenticación, exfiltración de datos) se implementó como un microservicio independiente con su propio consumer group de Kafka.

Apache Kafka sirvió como bus central de eventos con topics particionados por tipo de fuente de eventos. El pipeline procesaba eventos en tres etapas: ingesta (normalización y enriquecimiento), correlación (matching de reglas y scoring de amenazas) y acción (generación de alertas, respuesta automatizada). Cada etapa escalaba de forma independiente vía Kubernetes HPA basado en métricas de consumer lag, permitiendo al sistema absorber picos de tráfico de 5x sobre la línea base sin degradación de latencia.

Elasticsearch se desplegó como tier de almacenamiento hot-warm-cold para retención de eventos e investigación forense. Una estrategia de indexación personalizada con rollover basado en tiempo y optimización force-merge redujo los costes de almacenamiento en un 40% manteniendo latencia de búsqueda inferior al segundo para los 30 días más recientes de eventos. Redis se usó para gestión de estado en tiempo real: tracking de sesiones activas, scores de reputación de IP y cachés de indicadores de amenazas con expiración basada en TTL.

El pipeline ML se refactorizó para ejecutarse en un namespace separado de Kubernetes con node pools GPU para entrenamiento de modelos (Python/TensorFlow) y pods optimizados para CPU para inferencia (Go-wrapped TensorFlow Lite). Las actualizaciones de modelos se desplegaban mediante un mecanismo canary: los nuevos modelos recibían el 10% del tráfico junto al modelo de producción, con comparación automatizada de tasas de falsos positivos antes de la promoción.

Como staff augmentation, los ingenieros de Envadel siguieron los procesos de delivery existentes del cliente: sprints de 1 semana, trunk-based development con feature flags, pair programming para cambios complejos y una política estricta de "no commits directos a main". Los code reviews requerían aprobación de al menos un ingeniero del cliente y un ingeniero de Envadel para polinización cruzada.

El delivery manager de Envadel realizaba check-ins quincenales con el VP de Ingeniería y una revisión ejecutiva mensual cubriendo métricas de rendimiento individual, progreso de transferencia de conocimiento e hitos de la iniciativa de escalabilidad. Un canal dedicado de Slack proporcionaba visibilidad en tiempo real entre el liderazgo de Envadel y la dirección de ingeniería del cliente.

La transferencia de conocimiento se integró en el engagement desde el inicio. Cada ingeniero de Envadel realizaba "tech talks" semanales (sesiones internas de 30 min) cubriendo las decisiones arquitectónicas y patrones que se estaban introduciendo. Para el mes 6, los ingenieros internos del cliente construían y desplegaban de forma independiente nuevos microservicios de detección usando los patrones establecidos por el equipo augmented.