Tabla de Contenidos
Los problemas de escalado son dificultades que surgen cuando un sistema o aplicación no puede manejar cantidades exponencialmente mayores de datos o tráfico de usuarios. Recientemente escribimos sobre cómo freemium casi causa el colapso de nuestro negocio debido a tales problemas de escalado. Esta es una historia real de por qué escalar una aplicación nunca es tan fácil como parece.
Construir software es algo parecido a un consejero de campamento con los ojos bien abiertos y la cola esponjosa. Al principio, los niños son dejados por sus padres, uno o dos a la vez. Cada niño tiene alguna solicitud especial que debe ser manejada. Uno tiene un montón de equipaje para ser almacenado. Otro es vegano. Otro solo quiere hacer tiro con arco y nada más.
Está bien.
Luego, autobuses llenos de niños comienzan a ser dejados — todos que acampan de forma gratuita, pero todos tienen equipaje, restricciones dietéticas, problemas de planificación. Nada divertido.
Al final del día…el pobre consejero está agotado.
El software y los consejeros de campamento tienen mucho en común.
El rastro de buenas intenciones
- Escribe tu aplicación en Rails y usa Postgres — ¡Todo es genial!
- Agrega un webhook simple para Stripe en Rails como un controlador en la aplicación principal — ¡Estamos pateando!
- Comienza a calcular en segundo plano — usa Sidekiq — ¡Aún es genial!
- Hasta que un cliente se registra y envía 20,000+ eventos en un período de 24 horas.
- Ahora, ese webhook simple está causando que el panel principal sea lento
- Extrae el webhook hacia su propio microservicio pequeño — ha estado funcionando durante meses sin intervención…
- Importar datos de Stripe por meses funciona genial hasta que un cliente se registra con 8,000 eventos en un solo día.
- Ahora tenemos que importar por segmento (2–3 días de movimiento forward perdidos)
- En ese mismo tiempo, se registran más cuentas, necesitamos más workers… sin preocupaciones, ¡actívalos!
- Pero espera, workers de alta memoria en Heroku literalmente cuestan un brazo, una pierna, un riñón y el primogénito.
- Somos un negocio bootstrap, no podemos permitirnos gastar esto. Es hora de mudarse a AWS. Eso es totalmente razonable.
- Eeeek, ahora descargar datos para pruebas locales se vuelve casi imposible, lo que ralentiza el desarrollo. Suspiro.
- Problemas de workers resueltos.
- Oh, pero PG tiene un problema de límite de conexión que apenas vale la pena mencionar…
- Está bien, activa pgbouncer en cada máquina
- ¡Fantástico! Eso funciona, hasta que no — finalmente mudarse pgbouncer a su propia máquina — problemas de conexión resueltos
- Oh, pero mientras tanto, las consultas en el servidor de BD están matando la CPU
- En ese caso, extrae una tabla de alto tráfico hacia su propia BD separada
- Bueno, vaya, hay problemas de límite de conexión con la nueva BD (repetir lecciones aprendidas anteriormente)
- Oh, alguien se registró con 4,000 planes — todos nuestros workers por plan se están muriendo.
- Mientras tanto, el material de marketing en la aplicación principal funciona genial inicialmente
- Hasta que el marketing realmente funciona y miles de personas van a verlo
- Lo que mata el tiempo de respuesta del panel principal para clientes pagadores
- Lo que significa que tenemos que dividir rápidamente el sitio de marketing y la aplicación en piezas separadas
- Y así sucesivamente…
No podríamos haber sabido nada de esto al principio. Seguro, podríamos haber asumido optimizado para ello, pero entonces tampoco habríamos lanzado el producto en primer lugar porque estaríamos pasando toda la eternidad optimizando para el escalado que no teníamos.
Construir y, más importante, lanzar software se trata del compromiso constante entre el movimiento hacia adelante y la estabilidad presente.
Silicon Valley está lleno de tumbas de startups que nunca realmente lanzaron nada porque estaban empeñadas en arreglar problemas que no tenían. Lanzar es mejor que morir antes de dejar nunca la pista. Y sí, soy consciente de que es una metáfora torpe. Pero al menos la lancé. 🙂
