Caso 05 · Trabajo seleccionado
El suelo de ingeniería: miles de millones de impresiones y un mercado que se gestionaba solo
- Producción histórica — propiedad del empleador
Once años en dos etapas en la misma empresa de AdTech: cuatro como único ingeniero de frontend en una conversión de plataforma, después un mercado publicitario de autoservicio construido de principio a fin, y después servicios de backend que soportaban decenas de miles de peticiones por segundo.
- Papel
- Software Engineer, luego Senior Software Engineer
- Capacidades
- Escala · Plataforma · Ingeniería directa
- Ámbito
- Tecnología publicitaria — operaciones de editores, ventas y campañas
- Periodo
- Dos etapas, once años
Contexto
Una empresa de tecnología publicitaria con plataformas de editores, ventas y operación de campañas. Entré en 2011, salí en 2017 para montar mi propia empresa y me pidieron volver dos veces en los dos años siguientes; volví en 2019 con una categoría superior y me quedé durante la pandemia.
Problema y ambigüedad
Tres problemas distintos a lo largo de once años, pero una forma recurrente: algo que funcionaba a una escala dejaba de funcionar a la siguiente, y la solución nunca estaba en la parte que todos miraban.
Mi papel
Mi papel: años uno a cuatro, único ingeniero de frontend en la conversión de las interfaces de operación de la plataforma, más QA. Quinto año: pedí a mi responsable pasar al backend y lo conseguí — ⛔ no me reasignaron, lo pedí yo. Después construí el mercado publicitario B2B de autoservicio de la empresa, reportando directamente al CTO. En la segunda etapa dirigí las mejoras de backend y de API y la migración a una nueva superficie de API.
Levantamiento
Las interfaces de operación no eran un ejercicio de diseño, eran un problema de usabilidad con filo comercial: un embudo de ventas que lleva oportunidades por etapas de confianza hasta el acuerdo cerrado y de ahí al ciclo de vida de la campaña, un gestor de campañas sobre la jerarquía de país, anunciante, campaña, periodo, emplazamiento y creatividad, y un portal de editores que cubría configuración de huecos publicitarios, devengo de ingresos y solicitudes de pago. Acertar con eso exigía sentarse con operaciones publicitarias y con ventas, ⛔ no con una especificación.
Arquitectura y compromisos
El trabajo de escala fue una migración de una arquitectura heredada a una nueva superficie de API, y ambas mitades se reducían a lo mismo: sacar trabajo de la ruta de la petición. La telemetría publicitaria —cada impresión, cada clic y qué elemento dentro del anuncio se pulsó— habría inundado los servidores si cada evento lanzara su propia llamada, así que los eventos se acumulaban y se enviaban a intervalo fijo a un servicio de contabilidad aparte, se procesaban fuera del sistema principal y se escribían de vuelta. Los informes se generaban de forma síncrona, de modo que una página se bloqueaba mientras corría el suyo; eso pasó a lotes de trabajadores, con la página cargando de inmediato y el trabajo avisando al terminar.
Implementación e integración
El mercado era una superficie comercial completa: publicidad empaquetada en lotes y acuerdos, una capa de suscripción deliberadamente sencilla sobre un núcleo complejo, conectada al motor de API de la empresa, con autogestión y autopedido por parte del cliente, subida de creatividades, recarga y descuento de puntos de prepago del lado del comprador, y devengo de ingresos y solicitudes de pago del lado del editor. Los editores podían listar lotes, fijar sus emplazamientos y vender.
Controles de producción
El envío de informes se hizo idempotente: recargar la página no podía relanzar un trabajo que ya estaba corriendo, que es el fallo que todo usuario encuentra en una semana. Caché en varias capas, ajuste de consultas a base de datos y refactorización de Node.js en las rutas calientes.
Impacto
Escala de la plataforma: los servicios de backend soportaban decenas de miles de peticiones por segundo y miles de millones de impresiones publicitarias al mes. Esa cifra describe la plataforma, ⛔ no un componente que yo tuviera en exclusiva: trabajé sobre rutas de backend concretas dentro de ella. En esas rutas, el envío por lotes, el ajuste de consultas, la caché en varias capas y la refactorización de Node.js descritos arriba llevaron los tiempos de respuesta p95 por debajo de los 100 milisegundos, medidos en las rutas que se cambiaron.
Aprendizaje reutilizable
Las dos victorias de escala salieron del mismo movimiento —sacar el trabajo de la ruta de la petición— y ninguna exigió reescribir nada. La cifra de caudal es consecuencia de esa decisión, ⛔ no un logro por sí misma, y prefiero que me pregunten por el mecanismo antes que por el número.
Evidencia pública
Todo lo anterior es lo que se puede comentar públicamente. Lo que se reserva, y lo que está en preparación:
Esta década se sostiene mejor con un juego de diapositivas que con un repositorio — proyecto P8 — porque el trabajo es demasiado antiguo y demasiado propiedad del cliente como para reconstruirlo con honestidad.
Este es el método que hay detrás
Las respuestas salen de este sitio. Te dirá cuándo un proyecto no vale la pena construirlo.