Cómo Segment rediseñó sus sistemas centrales para resolver una crisis de escala existencial

Cómo Segment rediseñó sus sistemas centrales para resolver una crisis de escala existencial

Segmento, la startup Twilio, que se compró el otoño pasado por 3.200 millones de dólares, apenas comenzaba a despegar en 2015 cuando se encontró con un problema de escala: estaba creciendo tan rápido que las herramientas que había creado para procesar los datos de marketing en su plataforma comenzaban a superar el diseño del sistema original .

La inacción haría que la empresa chocara contra una pared tecnológica, temían los gerentes. Cada startup en etapa inicial anhela crecimiento y segmento no fue una excepción, pero también tenía que empezar a pensar en cómo hacer que su plataforma de datos fuera más resistente o llegar a un punto en el que ya no pudiera manejar los datos que estaba moviendo a través del sistema. Fue, en un sentido real, una crisis existencial para la empresa joven.

El proyecto que surgió de sus esfuerzos se llamó Centrifuge, y su propósito era mover datos a través de las tuberías de datos de Segment hacia donde los clientes los necesitaran de manera rápida y eficiente al menor costo operativo.

El equipo de ingeniería de Segment comenzó a pensar mucho en cómo sería un sistema más robusto y escalable. Al final resultó que, su visión evolucionaría de varias maneras entre finales de 2015 y hoy, y con cada iteración, darían un salto en términos de la eficiencia con la que asignaban los recursos y procesaban los datos que se movían a través de sus sistemas.

El proyecto que surgió de sus esfuerzos se llamó Centrifuge, y su propósito era mover datos a través de las tuberías de datos de Segment hacia donde los clientes los necesitaran de manera rápida y eficiente al menor costo operativo. Esta es la historia de cómo se unió ese sistema.

Dolores de crecimiento

Los problemas sistémicos se hicieron evidentes de la forma en que lo hacen a menudo: cuando los clientes comenzaron a quejarse. Cuando Tido Carriero, director de desarrollo de productos de Segment, se incorporó a finales de 2015, se le encargó la búsqueda de una solución. El problema involucraba el diseño del sistema original, que como muchas iteraciones tempranas de startups fue diseñado para llevar el producto al mercado sin pensar mucho en el crecimiento futuro y el pago de la deuda técnica estaba a punto de vencer.

“Tuvimos [designed] nuestra arquitectura de integraciones inicial de una manera que simplemente no era escalable de varias maneras diferentes. Habíamos experimentado un crecimiento masivo y nuestro CEO [Peter Reinhardt] vino a verme tal vez tres veces en un mes y me informó sobre varios desafíos de escala que los clientes o socios nuestros le habían alertado ”, dijo Carriero.

La buena noticia era que estaba atrayendo clientes y socios a la plataforma a un ritmo rápido, pero todo podría haberse derrumbado si la empresa no mejorara la arquitectura del sistema subyacente para respaldar el sólido crecimiento. Como informa Carriero, eso lo convirtió en un momento estresante, pero al venir de Dropbox, en realidad estaba en condiciones de comprender que es posible reestructurar completamente la plataforma tecnológica de la empresa y vivir para contarlo.

“Una de las cosas que aprendí de mi vida pasada [at Dropbox] Es cuando tienes un problema que es tan fundamental para tu negocio, en cierto punto empiezas a darte cuenta de que eres la única empresa en el mundo que experimenta este problema a este tipo de escala ”, dijo. Para Dropbox, que estaba relacionado con el almacenamiento, y para Segment, procesaba grandes cantidades de datos al mismo tiempo.

En la ecuación de construir versus comprar, Carriero sabía que tenía que construir su camino para salir del problema. No había nada que pudiera resolver los problemas de escala únicos de Segment. “Obviamente, eso nos llevó a creer que realmente necesitamos pensar en esto de manera un poco diferente, y fue entonces cuando nació nuestra arquitectura Centrifuge V2”, dijo.

Construyendo la bestia imperfecta

La empresa comenzó a medir el rendimiento del sistema, procesando en ese momento 8.442 eventos por segundo. Cuando comenzó a construir V2 de su arquitectura, ese número había aumentado a un promedio de 18,907 eventos por segundo.


Source link