Después de que la migración de nuestra app principal se completó y Datadog fue configurado en nuestro frontend, empezamos a recibir muchos errores, warnings y mensajes de debug en nuestro dashboard de DD. En algún momento, nuestro CTO preguntó por qué estábamos usando el modo Dev en nuestro entorno de producción.

Cuando nos preguntaron por qué el modo Dev estaba activado en producción, para ser honesto, no estaba al tanto de este comportamiento. Lo que escuché del equipo fue que lo necesitaban así para permitir el debugging de sus entornos locales, lo cual no tenía mucho sentido cuando se hablaba de producción. Después de nuestra conversación, fui puesto a cargo de arreglar el problema, y lo que encontré fue que, por defecto, estaba configurado en modo development y todos los builds estaban usando la misma configuración.

El otro día, durante una daily stand-up, estábamos discutiendo cómo mejorar la velocidad de nuestro sitio web principal. La mayoría de las soluciones propuestas estaban relacionadas con el caching a nivel de software. Mi propuesta fue un poco diferente, ya que en el pasado, cuando trabajaba en la infraestructura de Magento, descubrí Varnish.

Varnish es un software de caché que puede ser implementado como un proxy inverso. Todas las requests son recibidas primero por Varnish, y luego, basado en su archivo de configuración, la respuesta puede ser cacheada o permitir que la solicitud llegue al servidor de origen. La primera vez que Varnish inicia, cuando recibe una request, valida que no haya una copia cacheada de ella. Si no hay contenido cacheado, lo considerará un miss y pasará la request al servidor de origen. Si el archivo o contenido esta configurado para ser cacheado, guardará el contenido en memoria, y la próxima vez que la misma request llegue a tu servidor, regresara el contenido inmediatamente.

Debido al schedule establecido por el negocio, los payouts se ejecutan automáticamente dos veces por semana. Este ha sido el patrón por bastante tiempo, y aunque hemos propuesto extender el tiempo para los payouts para prevenir el fraude, aún no es una prioridad.

A veces recibimos reportes sobre actividades sospechosas con respecto a nuestros clientes, y usualmente después de la investigación, fui capaz de descubrir actividades fraudulentas. Es realmente interesante descubrir una operación de Scammers. Lo que usualmente hacen es usar tarjetas robadas y ejecutar pagos involucrando su cuenta. El problema viene cuando el dueño de la tarjeta levanta una disputa; la orden en estos casos es clara: reembolsar el dinero.

En el pasado, implementamos un CDN para reducir los costos de ancho de banda en un 80%, y la velocidad de nuestra página aumentó a medida que el CDN almacenaba imágenes en caché más cerca del usuario. Como una mejora adicional, propuse transformar las imágenes para hacerlas más pequeñas y usar un formato de última generación para reducir aún más el tamaño. En ese momento, el negocio no vio el valor en esto, pero unos meses después, ¿adivinen qué? Se me solicitó que revisara cómo podíamos mejorar la velocidad de la página de listado.

Cuando implementamos el flujo de despliegue basado en Trunk, nuestra pipeline a prod se aceleró mucho. Esto fue realmente genial, pero al mismo tiempo, estábamos produciendo más código del que el equipo de QA podía manejar, previniéndonos de desplegar features específicos a producción si algo ya estaba en la cola. De alguna manera resolvimos esto creando despliegues de feature branch, pero el problema era que los devs mergeaban a QA en lugar de desplegar a los ambientes de testing, causando el problema de nuevo.