3 puntos por GN⁺ 2025-10-21 | 1 comentarios | Compartir por WhatsApp
  • Postman sufrió temporalmente una interrupción del servicio por un problema global en la nube
  • El incidente fue causado por un problema del proveedor de la nube y provocó errores funcionales y un fallo intermitente de acceso para muchos usuarios
  • El equipo de ingeniería trabajó en la recuperación en tiempo real, mientras el servicio se restauraba de forma gradual
  • También se monitoreó y resolvió continuamente el error de algunas funciones de búsqueda y un problema de dependencia cruzada
  • Actualmente el incidente fue resuelto y el servicio se recuperó de manera normal, con monitoreo adicional de estabilidad en curso

Cronograma y proceso de recuperación de la caída del servicio de Postman

Detección del incidente e impacto (Oct 20, 05:39 ~ 05:52 PDT)

  • Se detectó un problema funcional debido al aumento de la tasa de errores en Postman
  • El origen de esta caída fue un incidente crítico en el proveedor de servicios en la nube
  • El equipo de Postman trabajó con el proveedor de nube para responder y agilizar la normalización del servicio

Recuperación parcial del servicio y monitoreo (Oct 20, 05:56 ~ 17:17 PDT)

  • Se observó una tendencia de recuperación en algunos sistemas
  • Se continuó monitoreando el rendimiento de múltiples servicios mientras se proseguía con las tareas de restauración completa
  • Se confirmó que la mayoría de las funciones se recuperó y se mantuvo el enfoque en evitar futuras caídas mediante monitoreo continuo

Recuperación total y normalización del servicio (Oct 20, 19:00 ~ 20:51 PDT)

  • Aunque quedaron algunos problemas intermitentes en ciertos servicios, la mayoría de los sistemas se recuperó de forma estable
  • Se resolvieron progresivamente tanto los errores de dependencia cruzada como los relacionados con la función de búsqueda
  • Tras resolver todos los problemas y completar la restauración completa del servicio, se realizó monitoreo adicional para asegurar la estabilidad

Resumen y lecciones

  • Postman tiene una alta dependencia del entorno en la nube, por lo que su arquitectura recibe impacto directo de una caída global
  • Se resalta la necesidad de que herramientas similares o servicios dependientes de funcionamiento local también se preparen para interrupciones de la infraestructura en la nube
  • Cuando ocurre una caída, el monitoreo de incidentes en tiempo real y la comunicación son críticos para el mantenimiento y la confianza de los clientes
  • Durante una recuperación gradual, es importante la respuesta rápida del equipo y una comunicación transparente
  • Vuelve a subrayarse la necesidad de establecer un sistema de monitoreo que verifique que todos los servicios estén operando correctamente

1 comentarios

 
GN⁺ 2025-10-21
Comentarios de Hacker News
  • Me pregunto si me estoy perdiendo algo por no usar Postman, así que como alternativa uso la función "Edit and Resend" de Firefox y para ejemplos reutilizables empleo scripts clásicos de curl.
    • En mi empresa lo usamos un poco: compartimos un archivo de colección con muchas solicitudes que incluyen headers y body para que los desarrolladores lo carguen fácilmente y prueben en sus propios servidores, y cambiar de servidor también se puede hacer con un clic. Como alternativa, puede ser un repositorio de Git con scripts de curl que incluyan variables de entorno; también lo usan personas no técnicas para ejecutar pruebas con Postman.
    • No es solo Postman; esos clientes permiten preparar y guardar muchas solicitudes de una sola vez para construir suites de pruebas. Algunos incluso brindan scripting y chaining de requests, entre otras funciones. Es un concepto parecido al de la diferencia entre un editor de texto y un IDE; al final es elegir según el nivel que cada uno necesita.
    • Lo más conveniente es que al copiar y pegar una URL, los parámetros se parsean automáticamente y todo se puede editar fácilmente desde la UI; fuera de eso, al final no difiere mucho del curl con el que ya estás familiarizado.
    • Hoy en día trabajo con Jupyter Notebook y requests; al final, al convertirlo todo a código de colección con Postman, terminás sintiéndote programando en un lenguaje bastante limitado.
  • Llama la atención que estas apps terminen usando Electron y la nube; en terminal habría bastado con una app TUI de 10 MB. Por cierto, existe una alternativa llamada posting.sh.
    • Me identifico con la idea de una app TUI de 10 MB; ahora las apps con Electron han crecido a escala de gigabytes. A modo de referencia: el paquete de vim es de 2,3 MB, curl 1,2 MB y lua 362 KB.
    • La razón de usar Electron es que originalmente comenzó como una extensión de Chrome y luego derivó a un formato standalone.
    • He usado hurl (https://hurl.dev/) durante años, pero me quedó una carpeta llena de archivos de texto desordenados, y esta vez voy a probar posting.sh.
    • Estaba buscando un reemplazo de Postman/Bruno/foo para usar en un servidor SSH o en un contenedor remoto de VS Code, y posting.sh encaja perfecto.
  • RubyMine y los IDE de JetBrains relacionados incluyen un cliente HTTP potente (Tools -> HTTP Client), y después de que Postman se complicó, encaja bien cuando solo necesitás hacer requests web. No es para menospreciar a quienes les gusta Postman, sino que a mí me suena excesivo para mis necesidades.
    • El cliente HTTP de JetBrains es muy bueno: si pegas un comando curl, lo convierte y lo formatea automáticamente, y también podés copiarlo de vuelta a curl con los cambios que hiciste.
  • Por eso surgió Yaak (https://yaak.app), porque es 100% offline, sin telemetría, open source y con soporte de integración con Git.
    • Tengo curiosidad por la estructura de licenciamiento comercial de Yaak: si la Pro license se basa en el principio de buena fe, me pregunto qué diferencia tiene con la licencia MIT. Al estudiar licencias comerciales open source, siempre me pregunté qué funciona mejor en cada escenario.
    • Lo estoy usando desde hace 6-9 meses y, al principio, compilaba desde el código fuente; hoy ya me pasé a usuario pago. Al ver que Yaak hace público su número de suscriptores e ingresos como open metrics, se ve bien una operación transparente.
    • Actualmente uso Bruno y también leí comparativas entre Bruno y Yaak. Si Bruno soporta todo lo que quiero, me gustaría escuchar en qué se diferencia Yaak de Bruno.
    • Me genera curiosidad si esto es una nueva herramienta competitiva nacida después de crear y vender Insomnia; no sé si hubo restricciones al momento de la venta.
    • Como amaba muchísimo Insomnia antes de la adquisición, me da mucha alegría que Yaak aparezca como su heredero espiritual; apoyo a Greg.
  • Dependiendo del caso de uso, muchas veces no hace falta una app separada: JetBrains (Información), Visual Studio (Información), VSCode (Información) ya soportan archivos http.
    • En VSCode, esto lo hizo un desarrollador anónimo como plugin; al ser función nativa no se nota del todo.
    • En nuestra organización, como QA (que no son desarrolladores) usa mucho la API HTTP, ahora Bruno está cumpliendo bien ese rol.
    • El formato de archivo http no es idéntico en todos los productos, por eso en nuestro equipo usamos hurl, QA prefiere Robot Framework y algunos usan Bruno.
    • A mayor tamaño organizacional, más usamos grandes postman collections para documentación de APIs, regresión y QA, especialmente por la dependencia de la librería JavaScript y el código custom de Postman.
  • Creo que la mayoría ya aceptó que Postman se fue haciendo más pesado a medida que sumaba funciones y quedaba dependiente del online.
    • En mi empresa, después de que Postman pasó a online, enviaron un correo a toda la empresa pidiendo eliminar Postman, y hoy está registrado como software prohibido en la wiki del equipo de IT. Antes sí se usaba en todos lados.
    • A medida que Postman se va convirtiendo en la herramienta estándar de la industria, todos terminan adaptándose, incluso gente de negocio también usa Postman y compartir collections se volvió lo común. Yo no me gusta usarlo, pero cuando hay que compartir trabajo con APIs, no hay opción. El negocio de Postman anda bien, pero no siento que sea bueno para todos los usuarios.
  • Hice un reemplazo súper simple y liviano de Postman basado en YAML llamado yapi (https://github.com/jamierpond/yapi), y se puede usar así:
    yapi -c ./users.yapi.yaml
    
    Ejemplo de archivo yaml (incluyendo schema, url, method, path y la forma de indicar query params). Al ejecutar solo yapi, también se puede buscar fácil el archivo de configuración usando fzf.
    • Es un concepto muy interesante y, cuando uno se acostumbra al flujo, creo que se usa bastante bien. Me pregunto por qué tiene tan pocas métricas en GitHub, seguramente porque todos usan Postman.
  • Llevé mucho tiempo usando Paw y hace algunos años se fusionó con RapidAPI; es una app pequeña pero hace excelente ese trabajo. Últimamente la combino con Phoenix LiveBook notebook y el paquete Req, y trabajando con el lenguaje que quieras, podés transformar datos con total libertad. Si no conocés Elixir, Jupyter o algún otro sistema de notebooks también puede ser una alternativa.
  • La combinación Bruno + git es perfecta para nuestro equipo: versionamos las colecciones en el repositorio y podemos trabajar offline sin dependencias externas; debería haberlo hecho así desde antes.
    • Había un bug raro al hacer import por pegar curl, pero ya quedó solucionado; por lo demás estoy 100% satisfecho.
  • Dejé de usar Postman por completo desde 2018, porque me parecía demasiado incómodo tener que loguearte para hacer una query de API, y la usabilidad, sinceramente, no me resultaba muy atractiva.