Eventbrite: Cómo Reduje Costos de APIs Externas de $15K/Día a $40/Mes
Como Senior Software Engineer en Eventbrite (marzo 2022 - febrero 2025), fui responsable de costos y fiabilidad en los request paths críticos de la organización SEO/Growth. Esta es la historia de dos esfuerzos de ingeniería relacionados: una capa de caching cross-service que eliminó $15K/día en gasto de APIs externas, y una transición a la plataforma de Ads donde la observabilidad mejorada llevó a retirar un sistema ML de terceros de $60K/mes.
El problema: Dependencias externas caras y frágiles
Las superficies principales de homepage y discovery de Eventbrite dependían de múltiples integraciones con APIs externas. Cada carga de página disparaba llamadas redundantes entre servicios dependientes sin un boundary de caching compartido. Los costos eran concretos:
- $15K por día en cargos de APIs externas, acumulándose por llamadas redundantes entre servicios
- Sin deduplicación - los mismos datos se obtenían múltiples veces en diferentes request paths para el mismo render de página
- Pipeline de crawl/index frágil - cuando las APIs externas eran lentas o rate-limited, los crawlers de motores de búsqueda encontraban páginas degradadas, afectando la visibilidad orgánica
El equipo conocía el total de la factura. No teníamos visibilidad por servicio ni por call-path para saber a dónde se iba el dinero.
La arquitectura: Caching centralizado y deduplicación
Diseñé y construí una capa de caching y deduplicación cross-service que se ubicaba entre nuestros servicios y las integraciones con APIs externas. Los objetivos eran directos: eliminar llamadas redundantes, reducir latencia y obtener visibilidad de costos por path.
Capa de retrieval centralizada. En lugar de que cada servicio hiciera sus propias llamadas a APIs externas, introduje una capa compartida de retrieval con un cache unificado. Cuando el Servicio A obtenía datos que el Servicio B también necesitaba dentro del mismo ciclo de request, la segunda llamada pegaba al cache en lugar de la red.
Deduplicación de requests. Identifiqué que muchas llamadas externas eran requests semánticamente idénticos hechos con milisegundos de diferencia desde diferentes code paths. La capa de deduplicación colapsaba estos en un solo request saliente y distribuía la respuesta a todos los llamadores.
Estrategia de invalidación de cache. Los datos externos tenían requerimientos de frescura variables. Diseñé TTLs escalonados basados en la volatilidad de los datos: metadata de eventos cacheada agresivamente (cambia raramente), datos de precios con TTLs cortos (cambia frecuentemente), datos de disponibilidad siempre obtenidos en tiempo real. Esto aseguraba que nunca sirviéramos datos obsoletos donde importaba.
Instrumentación de costos por path. Cada llamada externa fue etiquetada con el servicio de origen y el request path, alimentando dashboards de observabilidad. Por primera vez, el equipo podía ver exactamente qué code paths generaban más gasto en APIs externas.
Resultados: Plataforma SEO/Growth
| Métrica | Antes | Después |
|--------|--------|-------|
| Volumen de llamadas a APIs externas | Baseline | -90% |
| Gasto diario en APIs | ~$15,000/día | ~$40/mes |
| Impresiones orgánicas (YoY) | Baseline | +482% |
| LCP (Core Web Vital) | 4.6s | 2.3s |
La reducción de costos fue dramática: de aproximadamente $450K/mes a unos $1,200/mes, una reducción de 99.7%. Pero las mejoras de rendimiento importaron igual. Al eliminar round-trips redundantes a la red, los tiempos de carga cayeron significativamente. La mejora de LCP de 4.6s a 2.3s (medida vía CrUX) vino del mismo rediseño arquitectónico: el retrieval centralizado eliminó waterfalls de requests en el frontend entre servicios dependientes.
El crecimiento de impresiones orgánicas (+482% YoY) no fue causado solo por el caching. Fue el efecto compuesto de páginas más rápidas, mejor eficiencia de crawl, y los pipelines de indexación distribuidos que mi compañero de equipo y yo estábamos construyendo en paralelo (cubierto en mi writeup de SEO/Growth). Pero la capa de caching fue un prerequisito: los crawlers no pueden indexar páginas que dan timeout.
La transición a la plataforma de Ads
En mi último año en Eventbrite, transicioné a la plataforma de Ads, donde re-arquitecté flujos de desarrollo entre tres sub-equipos e introduje observabilidad de presupuesto en tiempo real.
El problema: El cumplimiento de presupuesto (budget fulfillment), es decir cuánto del gasto de un anunciante realmente se despliega, era una caja negra. Los equipos no podían ver si las campañas estaban ejecutando al ritmo correcto hasta la facturación, días o semanas después.
Lo que construí: Una capa de observabilidad de presupuesto en tiempo real que le dio al equipo visibilidad inmediata del ritmo de gasto, tasas de cumplimiento y rendimiento de campañas. Esto fue instrumentación, no una feature nueva, pero instrumentación que cambió decisiones.
El resultado: El cumplimiento de presupuesto mejoró en 5%. Más importante aún, la visibilidad mejorada habilitó una decisión basada en datos para retirar un sistema ML de ranking de terceros que costaba aproximadamente $60K/mes. Los datos mostraron que la mejora marginal de ranking del sistema ML no justificaba su costo. Sin la capa de observabilidad, esa decisión habría seguido siendo un debate en vez de una decisión.
Aprendizajes
La visibilidad de costos cambia el comportamiento más rápido que la optimización de costos. La capa de caching fue técnicamente sencilla. Lo que la hizo impactante fue la instrumentación por path que venía con ella. Cuando los ingenieros podían ver que su code path generaba $3K/día en llamadas externas, empezaron a diseñar diferente sin que nadie se los pidiera. El mismo patrón se repitió en la plataforma de Ads: la visibilidad de presupuesto en tiempo real cambió las decisiones del equipo en días. Es el mismo principio que aplico en Sprints de Ingeniería en Producción: construye la observabilidad primero, luego optimiza lo que los datos te muestren.
La deduplicación es el patrón de caching de mayor apalancamiento. El caching tradicional pregunta "¿hemos visto esta consulta exacta antes?" La deduplicación pregunta "¿estamos haciendo el mismo request ahora mismo, en paralelo, desde diferentes llamadores?" En una arquitectura de microservicios donde el mismo render de página dispara múltiples servicios, la deduplicación captura desperdicio que el caching basado en TTL no detecta.
Los cambios de infraestructura se componen. La capa de caching mejoró la velocidad de página, lo que mejoró la eficiencia de crawl, lo que mejoró la indexación, lo que mejoró la visibilidad orgánica, lo que trajo más tráfico, lo que generó más ingresos. Ninguna métrica individual cuenta la historia. El aumento de 482% en impresiones fue el resultado compuesto de múltiples mejoras de infraestructura aterrizando en secuencia, incluyendo los pipelines de indexación distribuidos que mi compañero de equipo y yo construimos en paralelo. Pensamiento sistémico significa entender que un cambio de caching también es un cambio de rendimiento, también es un cambio de SEO, también es un cambio de ingresos.
Mide antes de cortar. En la plataforma de Ads, pude haber pasado meses tratando de optimizar el sistema ML de ranking. En lugar de eso, construí la observabilidad para medir si estaba funcionando. No lo estaba, al menos no lo suficiente para justificar $60K/mes. La optimización más barata es eliminar algo que no está generando lo que cuesta.
Trabaja Conmigo en Algo Similar
Si enfrentas desafíos similares de costos de retrieval (gasto descontrolado en APIs, sin visibilidad por path, o un sistema que funciona pero cuesta demasiado operar) el mismo enfoque aplica. Caching centralizado, capas de deduplicación e instrumentación de costos son patrones que aplico tanto en arquitecturas de IA como en arquitecturas de servicios tradicionales.
Explorar Servicios de Consultoría de IA o enviar una consulta - respondo dentro de un día hábil.