Cómo gastamos 30 000 USD en Firebase en menos de 72 horas

#UnaVacaPorDeLaCalle se convirtió en la campaña de crowdfunding más grande de Colombia, ¡recaudando 3 veces más que el récord anterior hasta el momento en solo dos días! También se convirtió en una de las mayores campañas de crowdfunding político de la historia.

El crowfunding, alternativa hasta para la financiación electoral _En colombia existen 13 plataformas de financiación colectiva online Francisco Rincón - [email protected]…_www.larepublica.co

UN GRAN ÉXITO PARA VAKI

Solo 48 horas después del lanzamiento de la campaña, habíamos alcanzado muchos récords. La campaña recaudó 3 veces más que el récord anterior en Colombia en ese momento. Llegamos a más de 2 millones de sesiones, más de 20 millones de páginas visitadas y recibimos más de 15 mil apoyos. Esto promedia a mil usuarios activos en el sitio en promedio y recopilando más de 20 apoyos por minuto.

Fue un gran éxito para nosotros, nuestro equipo de ingeniería estaba muy orgulloso y feliz, éramos virales y nuestro sitio estaba funcionando cada segundo. En ese momento estábamos celebrando mientras observábamos de cerca las analíticas.

La aplicación se estaba ejecutando, todos los seguidores podían apoyar y los comentarios en las redes sociales decían que la aplicación hacía que fuera realmente sencillo brindar apoyo. Estábamos muy orgullosos :)

No queríamos lanzar ninguna característica nueva con tantos usuarios en el sitio, así que decidimos fusionar una versión con Angular V.6 y lazzy en la que estábamos trabajando, era un buen momento para trabajar en eso, dijimos . El sitio empezó a cargar más lento, a algunos usuarios les tomó más de 30 segundos cargar la página. Eso fue raro. Nuestro equipo no se sentía cómodo con eso y no podíamos entender qué lo estaba causando y ahora teníamos nuestro código con una versión completamente nueva de Angular, y probablemente muchos otros errores en producción.

Nuestro equipo comenzó a apresurar esta nueva versión y refactorizar casi todo para cargar todo lo que podamos. Hicimos un refactor en vivo. Era un gran riesgo y queríamos que esta campaña fuera perfecta, ¡así que lo hicimos! En tan solo un día y medio, nuestro equipo tenía listo el primer lanzamiento en la nueva versión. Después de algunas pruebas, parecía que el refactor ayudó a la velocidad de la aplicación, pero no fue tan rápido como queríamos. Nuestro objetivo era cargar en 3 segundos y no estaba funcionando como esperábamos. Esta fue nuestra primera pista de que algo dentro de Firebase podría mejorarse.

Cuando accedimos al panel de control de Firebase, nos dimos cuenta de que, con tantos visitantes y soportes, nuestro servicio Firestore no solo estaba sobrecargado, sino que teníamos una gran deuda con Google, ¡habíamos gastado $ 30,356.56 USD en solo 72 horas!

Nuestro panel de facturación después

UN ERROR DE CÓDIGO MUY CARO

Desde que se lanzó la campaña, y durante las próximas 48 horas, usamos muchos recursos de Firestore, ¡nuestra facturación ascendió a $ 35,000 USD! Hicimos más de 46 MIL MILLONES de solicitudes a Firestore. Sí, mil millones con B.

Teníamos una subvención con Google Cloud por $25,000 USD en nuestra cuenta gracias al programa de aceleración de NXTP Labs del que formamos parte en 2017, por lo que nuestra deuda era de “solo” $10,000 USD en ese momento. El verdadero problema era que cada hora nos costaba $600 USD más en Google Cloud Services. En ese momento teníamos dos opciones: cerrar el sitio para detener la facturación o comenzar a depurar cada línea de código con un reloj de dinero en la mesa. Elegimos el segundo.

No sabíamos dónde podíamos optimizar las solicitudes. Pensamos que nuestra empresa no sería rentable si usábamos Firebase como nuestro proveedor de alojamiento y ya nos estábamos estresando por la necesidad de llevar nuestros datos a otro lugar. ¡Con solo unas pocas horas más de vida que nos quedan, encontramos la línea! Fue solo una mala línea de código la que causó esa cantidad de solicitudes (y costos): this.loadPayments()

Para entender esto, déjame explicarte cómo funciona nuestra arquitectura. Tenemos dos colecciones principales en Firestore: Vakis y Payments . Vakis tiene los documentos con los datos de pago de cada Vaki y Pagos los documentos con los datos de pago de cada usuario.

Una de nuestras características es mostrar al usuario la cantidad total de dinero y seguidores que ha recibido un Vaki en tiempo real. Entonces tenemos los dos servicios que cargan esta información en el lado del cliente, v_akis.ts_ y pagos.ts .

Cada vez que se aprueba un pago, actualizamos un valor en el documento Vaki con los nuevos totales. Entonces solo necesitamos leer la colección Vakis para imprimir esa información. Pero, nuestro gran error, fue ignorar eso y calcular los totales leyendo de la colección Pagos.

Cada vez que llamamos al servicio vakis.ts , en el método constructor estaba la línea this.loadPayments() que llamaba al servicio de pagos.ts y con ese servicio estábamos imprimiendo la información de un Vaki. Esto significa que con cada visitante a nuestro sitio, necesitábamos llamar a cada documento de pagos para ver la cantidad de apoyos de un Vaki, o el total recaudado. En cada página de nuestra aplicación!

Esto significa que cada sesión a nuestro sitio lee la misma cantidad de documentos que tenemos de cantidad de pagos. #UnaVacaPorDeLaCalle recibió más de 16,000 seguidores, así: 2 millones de sesiones x 16,000 documentos = más de 40 mil millones de solicitudes a Firestore en menos de 48 horas.

¡GOOGLE ENTIENDE Y NOS POTENCIA!

Después de corregir este error de código y detener la facturación, nos comunicamos con Google para informarles el caso y ver si podíamos solicitar la próxima subvención que tienen para nuevas empresas. Les dijimos que gastamos la subvención completa de 25k que teníamos hace solo unos días y vemos la posibilidad de solicitar la subvención de 100k en Google Cloud Services. Contactamos con el equipo de Google Developers Latam, para contarles lo que acababa de pasar. Nos permitieron solicitar la próxima subvención, que Google aprobó, y después de algunas reuniones con ellos, nos permitieron pagar nuestra factura con la subvención.

Ahora no podríamos estar más agradecidos con Google , no solo por tener un increíble "Backend como servicio" como Firebase, sino también por permitirnos tener 2 millones de sesiones, 60 soportes por minuto y miles de millones de solicitudes sin dejar que nuestro sitio se caiga. Además, entendieron que errores como el nuestro pueden ocurrir cuando una startup está creciendo y algunos errores costosos pueden poner en peligro el futuro de grandes empresas.

CONCLUSIÓN

Es muy importante que los equipos técnicos depuren cada solicitud a los servidores antes del lanzamiento. Analice si la cantidad de solicitudes y la transferencia de datos tienen sentido, y si su empresa soportará los costos del host con una gran carga de tráfico. De lo contrario, solo atrapará bucles o solicitudes no óptimas con una factura enorme o con su sitio inactivo.

Además, si eres una startup que usa cualquier metodología Lean para lanzar rápido, fallar rápido, aprender rápido, ten cuidado, la agilidad tecnológica y la perfección tecnológica no son buenos amigos, y necesitas encontrar un buen equilibrio entre ellos para evitar errores costosos. , pero sigue moviendo tu negocio lo más rápido que puedas.

Gracias Google, gracias Karen, Paco y Martín (Team Google Developers Latam), gracias NXTP Labs. Sin ustedes, no podríamos soportar nuestra primera campaña viral 👊

Gracias a Juan Pablo Muriel, Katharine Vander Laan, Laura Cardona, Santiago Jaramillo y el Equipo Vaki por leer y comentar los borradores de este artículo.