Alta Disponibilidad en Micorservicios: el Caso de la Plataforma Fury de Mercado Libre

Thiago Veiga Lima; Vinicius Santos Andrade

DOI: 10.22167/2675-6528-202602380

Artículo derivado del Trabajo de Conclusión de Curso (TCC), con contenido basado en el trabajo original del alumno y adaptado al formato editorial de la Revista E&S con el apoyo de la herramienta ResumeAI, solución de inteligencia artificial desarrollada por el Instituto Pecege para síntesis y organización textual.

Resumen

La escalabilidad y la resiliencia de las plataformas de software representan desafíos centrales para las empresas de tecnología que operan a gran escala. Se investigó cómo la plataforma interna de desarrollo Fury, creada y mantenida por Mercado Livre, implementó mecanismos de alta disponibilidad (HA) en un ecosistema de microservicios que abarca más de 30.000 servicios ejecutándose en 100.000 instancias en producción. La investigación combinó revisión bibliográfica sobre patrones de resiliencia (circuit breaker, retry con backoff exponencial, bulkheads y rate limiting), análisis documental de publicaciones técnicas de Mercado Livre y levantamiento de campo aplicado a 20 ingenieros y tech leads que utilizan o gestionan aplicaciones en la plataforma. Los resultados indicaron que Fury redujo significativamente la carga cognitiva de los equipos de desarrollo al abstraer capas de infraestructura, automatizar pipelines de integración continua y entrega continua (CI/CD) y ofrecer estrategias de deploy como blue-green con rollback inmediato. La observabilidad nativa, sin embargo, fue evaluada como solo parcialmente suficiente por la mayoría de los encuestados, evidenciando una brecha que la organización está abordando con integración a herramientas de mercado. Se concluyó que el modelo de Internal Developer Platform (IDP) adoptado por Mercado Livre es un ejemplo de cómo prácticas de DevOps, microservicios y multicloud pueden combinarse para sostener alta disponibilidad en entornos de alta complejidad operativa. Esta visión sistémica de la disponibilidad es una contribución relevante para la literatura sobre IDPs.

Palabras clave: Alta Disponibilidad; DevOps; Fury; Plataforma Interna de Desarrollador; Microsservicios.

1. Introducción

La confiabilidad de los servicios digitales ha dejado de ser un diferencial competitivo para convertirse en una exigencia básica del mercado. En plataformas de comercio electrónico y servicios financieros que operan veinticuatro horas al día, siete días a la semana, la indisponibilidad de un componente puede significar pérdida directa de ingresos, erosión de la confianza del consumidor y, en casos extremos, impactos regulatorios. Este escenario subraya la importancia crítica de sistemas robustos capaces de mantener la operación continua incluso bajo condiciones adversas.

Mercado Livre, reconocido como el ecosistema de comercio electrónico y servicios financieros más grande de América Latina, ejemplifica este desafío. Con operaciones en dieciocho países y más de cien millones de usuarios activos, su estructura exige que los equipos de ingeniería gestionen decenas de miles de microsservicios interdependientes. Estos servicios están constantemente sujetos a picos de demanda impredecibles, especialmente durante eventos como el Día del Consumidor o el Black Friday. Asegurar la funcionalidad continua a esta escala demanda mecanismos sofisticados para alta disponibilidad.

En este contexto altamente complejo y dinámico, la pregunta central de esta investigación fue: ¿cómo una plataforma interna de desarrollo puede garantizar alta disponibilidad a escala de decenas de miles de microservicios, manteniendo la productividad de más de 15.000 ingenieros? Este desafío evidencia la necesidad de enfoques sistemáticos para construir plataformas de software resilientes a una escala excepcional.

La alta disponibilidad (HA) se define como la capacidad de un sistema para permanecer operativo durante un determinado porcentaje de tiempo dentro de un período de referencia, generalmente expresado en ‘nueves’. Por ejemplo, el 99,9% de disponibilidad equivale a aproximadamente ocho horas y cuarenta minutos de inactividad al año, mientras que el 99,99% reduce este número a unos cincuenta y dos minutos (Tanenbaum y Van Steen, 2016). Los fundamentos teóricos de la HA se remontan al teorema CAP, formulado por Brewer (2000) y formalizado por Gilbert y Lynch (2002), que establece que ningún sistema distribuido puede garantizar simultáneamente consistencia total, disponibilidad total y tolerancia a particiones de red. Las arquitecturas orientadas a la alta disponibilidad tienden a privilegiar la disponibilidad y la tolerancia a particiones, aceptando la inconsistencia eventual, un modelo conocido como BASE (Basically Available, Soft State, Eventually Consistent). La ingeniería de confiabilidad de sitios (SRE) ha consolidado prácticas como la definición de Objetivos de Nivel de Servicio (SLOs), Indicadores de Nivel de Servicio (SLIs) y presupuestos de error, que permiten equilibrar la velocidad de lanzamiento de funcionalidades con el mantenimiento de la confiabilidad del servicio (Beyer et al., 2016).

La adopción de arquitecturas de microservicios ha traído patrones de resiliencia ampliamente documentados. El circuit breaker interrumpe las llamadas a servicios con fallas y devuelve respuestas de fallback, evitando la propagación en cascada (Nygard, 2007; Fowler, 2014). El retry con backoff exponencial repite las llamadas con intervalos crecientes, añadiendo jitter para evitar el fenómeno thundering herd (Amazon Web Services, 2023). Los bulkheads aíslan pools de recursos por dependencia y el rate limiting protege los servicios de picos de tráfico abusivo (Richardson, 2018). El concepto de Internal Developer Platform (IDP) surgió como respuesta a la complejidad operativa de los entornos de microservicios, ofreciendo una capa de autoservicio que permite a los desarrolladores crear, desplegar y monitorizar aplicaciones sin interactuar directamente con la infraestructura subyacente (Humanitec, 2023). La estrategia multicloud, que implica el uso simultáneo de proveedores como AWS y GCP, complementa este modelo al aumentar la disponibilidad por redundancia geográfica y reducir el riesgo de vendor lock-in (Gartner, 2022).

La relevancia del tema trasciende los límites de la empresa estudiada, ya que comprender cómo estos patrones de resiliencia se materializan en una plataforma de uso real, a escala real, es un ejercicio valioso tanto para investigadores como para profesionales que necesitan tomar decisiones de arquitectura en el día a día. Desde el punto de vista académico, el trabajo se inserta en la intersección de múltiples disciplinas exploradas a lo largo del MBA en Ingeniería de Software de la USP/ESALQ: microsservicios, DevOps, orquestación de contenedores con Kubernetes, observabilidad y monitoreo, infraestructura como código y cloud computing. Así, este trabajo analizó cómo Mercado Libre enfrentó el desafío de la alta disponibilidad al construir la plataforma interna Fury, investigando los patrones de resiliencia empleados, los resultados obtenidos en campo y las lecciones que este caso ofrece a la ingeniería de software contemporánea.

2. Material y Métodos

La presente investigación se caracterizó, por su naturaleza, como aplicada, ya que se orientó a la solución de un problema práctico relacionado con la implementación de alta disponibilidad en entornos de microservicios. En cuanto al enfoque, se adoptó un diseño predominantemente cualitativo, complementado por elementos cuantitativos en la etapa de análisis de los datos recopilados mediante cuestionario. En lo que respecta a los objetivos, el estudio se clasificó como exploratorio-descriptivo, buscando explorar la plataforma Fury, que posee documentación pública limitada, y describir sistemáticamente sus mecanismos de resiliencia (Gil, 2017).

La estrategia de investigación empleada fue el estudio de caso único incrustado, según lo propuesto por Yin (2015). La plataforma Fury, desarrollada y mantenida por Mercado Libre, constituyó la unidad primaria de análisis. Esta elección se justificó por la singularidad del caso, dada la ausencia de otra plataforma interna de desarrollo en América Latina que presente una escala y madurez comparables, lo que la convierte en un objeto de estudio relevante para la ingeniería de software.

Para la recolección de datos, se utilizaron tres fuentes complementarias, con el objetivo de triangular y aumentar la validez interna de la investigación. La primera fuente consistió en una revisión bibliográfica exhaustiva, que incluyó libros, artículos científicos y documentación técnica especializada sobre alta disponibilidad, estándares de resiliencia y plataformas internas de desarrollo.

La segunda fuente de datos implicó el análisis documental de publicaciones técnicas divulgadas por el propio Mercado Libre. Se examinaron artículos publicados en Medium Engineering (Martins, 2024), presentaciones realizadas en conferencias públicas, como la PlatformCon 2023, y repositorios de código abierto mantenidos por la organización. Este enfoque permitió comprender las estrategias e implementaciones de la plataforma Fury a partir de materiales oficiales.

La tercera fuente de datos fue una encuesta de campo, realizada mediante la aplicación de un cuestionario estructurado. Este instrumento se dirigió a profesionales que utilizan o gestionan aplicaciones en la plataforma Fury en Mercado Libre. El cuestionario buscó recopilar percepciones e información directa de los usuarios sobre la operacionalización de la alta disponibilidad.

El instrumento de recolección de datos consistió en un cuestionario estructurado, cuyo contenido integral se detalla en el Anexo A del trabajo original. La aplicación del cuestionario se realizó de forma digital, utilizando la plataforma Google Forms, entre los meses de febrero y abril de 2026. Este método garantizó la estandarización de la recolección y la facilidad de acceso a los participantes.

Veinte profesionales de Mercado Livre participaron en el estudio de campo, incluyendo ingenieros de software y líderes técnicos o jefes de proyecto. El cuestionario constó de siete preguntas que abordaron aspectos como el perfil y el tiempo de experiencia de los encuestados con la plataforma Fury, los patrones de resiliencia identificados, la evaluación de la facilidad de implementación de alta disponibilidad en comparación con la construcción desde cero, los desafíos técnicos enfrentados, la suficiencia de las herramientas de observabilidad nativas y las métricas consideradas vitales para la salud de las aplicaciones.

El análisis de los datos recolectados se realizó en dos etapas. Los datos de naturaleza cuantitativa, obtenidos a partir de las preguntas cerradas del cuestionario, fueron sometidos a estadística descriptiva simple, con el cálculo de frecuencia absoluta y porcentual. Este enfoque permitió cuantificar la distribución de las respuestas e identificar tendencias generales.

Los datos cualitativos, provenientes de las respuestas abiertas del cuestionario, fueron sometidos al análisis de contenido temático, conforme a la metodología de Bardin (2016). Por medio de esta técnica, se identificaron categorías emergentes a partir de la recurrencia de temas y conceptos en las respuestas de los participantes. Se empleó la triangulación entre las tres fuentes de datos —revisión bibliográfica, análisis documental y levantamiento de campo— para fortalecer la validez interna de las conclusiones de la investigación.

Los cuidados éticos se observaron rigurosamente durante todas las etapas de la investigación. El estudio se llevó a cabo de conformidad con la Resolución CNS nº 510, de abril de 2016, del Consejo Nacional de Salud. La investigación se encuadró en las excepciones de los incisos I y VII del artículo 1º de la referida resolución, por utilizar información recopilada de forma anónima en un entorno profesional, garantizando la privacidad y confidencialidad de los participantes.

3. Resultados y Discusión

La investigación sobre la plataforma Fury de Mercado Libre reveló un conjunto robusto de estrategias y mecanismos que sustentan la alta disponibilidad en un ecosistema de microservicios a gran escala. Los hallazgos indican que la plataforma actúa como una capa de abstracción eficaz, reduciendo la carga cognitiva de los desarrolladores y automatizando procesos críticos de infraestructura y despliegue. La investigación combinó el análisis de publicaciones técnicas de la empresa con un estudio de campo junto a 20 ingenieros y líderes técnicos, proporcionando una visión multifacética de la implementación y percepción de los patrones de resiliencia. Los resultados confirman la relevancia del modelo de Plataforma Interna de Desarrolladores (IDP) para gestionar la complejidad operativa inherente a entornos distribuidos, al mismo tiempo que señalan desafíos persistentes, especialmente en el campo de la observabilidad nativa.

Historial y contexto de creación del Fury

La evolución de la plataforma Fury está intrínsecamente ligada al crecimiento exponencial de Mercado Libre, que en 1999 operaba sobre una arquitectura monolítica con cientos de servidores y una única base de datos. Esta estructura, aunque funcional inicialmente, se convirtió en un cuello de botella severo, resultando en despliegues semanales con congelamiento de código, pruebas lentas y conflictos entre equipos (Martins, 2024). La migración a microservicios alrededor de 2010 y el lanzamiento de MeliCloud, la primera infraestructura como servicio interna, representaron un avance significativo, con más de 1.400 instancias desplegadas diariamente y 17.500 instancias gestionadas. Sin embargo, MeliCloud introdujo una heterogeneidad excesiva, donde cada equipo definía su propia infraestructura, dificultando la consistencia y la estandarización.

Esta experiencia llevó a la formulación de un principio central para el diseño de Fury: permitir que un desarrollador tenga una aplicación en producción con solo tres clics. Lanzada en 2015, la plataforma interna de desarrollo Fury materializó este principio, buscando abstraer la complejidad de la infraestructura y estandarizar el ciclo de vida del software. Este enfoque de desarrollo buscaba no solo aumentar la productividad de los ingenieros, sino también garantizar que los mecanismos de alta disponibilidad se incorporaran de forma intrínseca al proceso de desarrollo y operación, facilitando la escalabilidad y la resiliencia del ecosistema de microsservicios.

Arquitectura y componentes principales

Fury opera como una Plataforma de Desarrollador Interna (IDP) integral, que abstrae la totalidad de la cadena de creación, configuración, despliegue y monitoreo de aplicaciones. La interacción con la plataforma se realiza a través de una interfaz web y una Interfaz de Línea de Comandos (CLI), simplificando el acceso y la gestión para los desarrolladores. El concepto organizacional central es el “Scope”, que representa un entorno de ejecución simplificado dentro de un proveedor de nube, ya sea para desarrollo, homologación o producción. Al crear un scope, Fury aprovisiona automáticamente componentes esenciales como balanceadores de carga, grupos de autoescalado e instancias, además de configurar logs, métricas y alertas, todo de forma transparente para el usuario.

La plataforma actúa como una capa de abstracción crucial entre las aplicaciones de los desarrolladores y los servicios externos, incluidos proveedores como AWS, GCP y la infraestructura on-premises de Mercado Livre. Las aplicaciones no se comunican directamente con estos servicios en la nube; en su lugar, se emplea una capa anticorrupción para prevenir el lock-in, facilitar las actualizaciones de versión y permitir el cambio de proveedores sin necesidad de modificar el código de la aplicación (Martins, 2024b). Esta arquitectura simplificada pero potente es fundamental para mantener la alta disponibilidad, ya que aísla las aplicaciones de la complejidad subyacente de la infraestructura.

El Release Process, implementado desde 2018, es un componente vital de Fury, gestionando más de 26.000 repositorios y ejecutando automáticamente siete validaciones de calidad en cada integración. Estas validaciones incluyen verificación de dependencias, modelo de branching, cobertura de pruebas y análisis de credenciales hardcoded, garantizando la integridad y seguridad del código. En 2024, la plataforma ya procesaba más de 30.000 deploys por día a través de este pipeline (Carvalho, 2024), demostrando la capacidad de entrega continua a gran escala. Los indicadores operativos de la plataforma en 2024 son notables, con más de 30.000 microservicios en producción, más de 100.000 instancias de producción, más de 15.000 ingenieros utilizando la plataforma y más de 26.000 repositorios gestionados, además de los 30.000 deploys diarios.

Mecanismos de alta disponibilidad en Fury

La alta disponibilidad en Fury no es una funcionalidad aislada, sino una propiedad emergente de un diseño sistémico que incorpora resiliencia en tres capas interconectadas: infraestructura, despliegue y aplicación. En la capa de infraestructura, el escalado automático es el mecanismo más prominente. Cuando se crea un scope, la plataforma configura grupos de escalado automático que ajustan el número de instancias en función de métricas como CPU, memoria y volumen de peticiones, de forma transparente para el desarrollador. Esta gestión de escalado automático se desarrolló internamente para soportar una solución multi-vendor, sin depender exclusivamente de servicios específicos de proveedores de nube (Martins, 2024b). La distribución de cargas de trabajo por múltiples zonas de disponibilidad complementa el escalado automático, asegurando que la falla de un centro de datos no comprometa la disponibilidad del servicio.

En la capa de despliegue, Fury ofrece diversas estrategias para garantizar la continuidad de las operaciones durante las actualizaciones. Entre las cinco estrategias disponibles (All-in, Blue-Green, Canary, Safe Deploy y Migration), Blue-Green es la opción predeterminada para servicios críticos. Crea un nuevo entorno en paralelo, migra el tráfico gradualmente y permite un rollback inmediato sin tiempo de inactividad. Safe Deploy es una variación que monitoriza métricas continuamente y automatiza decisiones de rollback cuando se detectan anomalías, reforzando la resiliencia del proceso de implementación. Estas estrategias son cruciales para mantener una alta disponibilidad, minimizando el impacto de nuevas versiones.

En la capa de aplicación, los patrones de resiliencia ampliamente reconocidos en la literatura se ofrecen como primitivas nativas de la plataforma. El circuit breaker interrumpe llamadas a servicios con fallos, devolviendo respuestas de fallback y previniendo la propagación en cascada (Nygard, 2007; Fowler, 2014). El retry con backoff exponencial repite llamadas con intervalos crecientes, añadiendo jitter para evitar el fenómeno thundering herd (Amazon Web Services, 2023). Los bulkheads aíslan pools de recursos por dependencia, y el rate limiting protege servicios de picos de tráfico abusivo (Richardson, 2018). La separación de aplicaciones críticas en scopes independientes funciona como un bulkhead a nivel de infraestructura, garantizando que problemas en un scope no afecten a los demás. Estos patrones, integrados en la plataforma, son esenciales para la robustez de los microservicios.

Observabilidad y monitoreo

La observabilidad, definida como la capacidad de inferir el estado interno de un sistema a partir de sus salidas externas, es un pilar inseparable de la alta disponibilidad. Sin una visibilidad adecuada sobre lo que ocurre en producción, incluso los diseños de resiliencia más sofisticados pueden fallar silenciosamente durante largos períodos antes de ser detectados (Majors, Fong-Jones y Miranda, 2022). Fury ofrece, de forma nativa, monitoreo de métricas de infraestructura, incluyendo CPU, memoria, tráfico, latencia y tasa de errores. Además, la plataforma centraliza logs y permite la configuración de alertas, con integraciones a herramientas de mercado como DataDog, New Relic y OpsGenie. El monitoreo se extiende a reglas de negocio específicas, como picos en el tiempo de procesamiento de pagos, proporcionando una visión integral de la salud de las aplicaciones.

Evolución a multicloud y GenAI

La estrategia multicloud de Fury abstrae los proveedores subyacentes, como AWS y GCP, presentando a los desarrolladores una interfaz unificada e independiente de la infraestructura utilizada. Este diseño tiene implicaciones directas para la alta disponibilidad, ya que la distribución de cargas de trabajo entre proveedores distintos reduce el riesgo de que un incidente en un proveedor específico afecte toda la operación. La abstracción multicloud se habilita mediante el uso de Kubernetes para la orquestación de contenedores, Terraform para el aprovisionamiento de infraestructura como código y una capa propietaria de automatización que incorpora las convenciones y políticas de seguridad de Mercado Libre. Actualmente, alrededor del 20% de la infraestructura aún opera fuera de Fury, en lo que se denomina mundo Off-Fury, gestionado por herramientas de Infraestructura como Código para mantener la conformidad y la visibilidad (Martins, 2024b).

El próximo paso anunciado por la empresa es la integración con inteligencia artificial generativa (GenAI), en asociación con OpenAI, para crear soluciones disruptivas en el ecosistema de desarrollo. Esta iniciativa tiene como objetivo utilizar la IA en la optimización de rutas de tráfico, en la detección predictiva de anomalías y en la generación automática de código con patrones de resiliencia integrados. Estas tendencias se alinean con el concepto de AIOps (Inteligencia Artificial para Operaciones de TI), que busca automatizar y optimizar las operaciones de TI a través de inteligencia artificial, prometiendo avances significativos en el mantenimiento de la alta disponibilidad y en la eficiencia operativa de la plataforma Fury.

Perfil de los encuestados

El levantamiento de campo se realizó con 20 profesionales de Mercado Libre entre febrero y abril de 2026. La mayoría de los encuestados, 16 (80%), eran ingenieros de software o desarrolladores, mientras que 4 (20%) eran tech leads o project leaders. En cuanto al tiempo de experiencia con la plataforma Fury, la predominancia de encuestados con menos de un año de uso refleja el rápido crecimiento del equipo de ingeniería de Mercado Libre y el ciclo continuo de incorporación de nuevos colaboradores. Sin embargo, la presencia de 4 (20%) profesionales con más de tres años de experiencia y 2 (10%) con experiencia entre uno y tres años proporcionó perspectivas valiosas sobre la evolución y los desafíos de la plataforma a lo largo del tiempo, enriqueciendo el análisis cualitativo de los mecanismos de resiliencia.

Patrones de resiliencia identificados

Cuando se les preguntó sobre los patrones de resiliencia más efectivos en la plataforma Fury, los encuestados pudieron seleccionar múltiples opciones, revelando la percepción de uso y la prominencia de cada mecanismo. Los patrones Retry con Backoff y Rate Limiting fueron los más citados, mencionados por 15 de los 20 encuestados, lo que corresponde al 75% de las menciones. El Circuit Breaker fue identificado por 13 encuestados (65%), mientras que Bulkheads fue citado por 9 (45%) y Fallback Strategies por 7 (35%). Estos datos indican que Retry con Backoff y Rate Limiting son los primeros mecanismos de protección con los que interactúan los nuevos usuarios de Fury, mientras que Bulkheads y Fallback Strategies requieren una mayor madurez en el uso de la plataforma para ser plenamente percibidos y utilizados por los desarrolladores.

La facilidad de implementación de alta disponibilidad en Fury, en comparación con la construcción de soluciones desde cero, fue evaluada con un promedio de 4.6 en una escala de 1 a 5, donde 5 representa “muy fácil”. Solo un encuestado otorgó una calificación de 3, justificándola con dificultades en la gestión de tiempos de espera (timeouts), mientras que los demás otorgaron calificaciones de 4 o 5. Esta percepción general de alta facilidad sugiere que Fury simplifica sustancialmente la implementación de mecanismos de alta disponibilidad. Uno de los encuestados sintetizó esta percepción al afirmar que, hasta el momento de la investigación, la plataforma había garantizado alta disponibilidad sin que su equipo necesitara acciones adicionales, evidenciando la eficacia de la abstracción y automatización ofrecidas por Fury.

Desafíos técnicos y brechas observadas

Las respuestas abiertas sobre los desafíos técnicos revelaron tres categorías principales. La primera, mencionada por cuatro encuestados, fue la curva de aprendizaje y la necesidad de un conocimiento profundo del ecosistema. Al ser una plataforma propietaria con documentación interna, Fury presenta una curva de aprendizaje sin abundantes referencias externas, a diferencia de servicios de nube públicos como AWS, Azure y GCP. Este aislamiento del conocimiento es una consecuencia paradójica del éxito de la abstracción: cuanto más la plataforma oculta la complejidad, menos el desarrollador comprende qué hacer cuando ocurren problemas, lo que puede dificultar la resolución de incidentes.

La segunda categoría de desafíos fue la complejidad del entorno distribuido. Un encuestado destacó que lidiar con un entorno altamente distribuido, repleto de dependencias y con despliegues continuos, es el mayor obstáculo. Cualquier lentitud o fallo en un servicio puede desencadenar un efecto cascada en otros, evidenciando que, si bien los patrones de resiliencia son eficaces, gestionan la complejidad inherente a los sistemas distribuidos, pero no la eliminan por completo. La interconexión de los microservicios exige una comprensión profunda de las interacciones para mitigar riesgos de fallos en cascada, incluso con la implementación de patrones de resiliencia.

La tercera categoría de desafíos fue la observabilidad y el diagnóstico de incidentes. Entre los 20 encuestados, 13 (65%) afirmaron que la visibilidad nativa de Fury es solo parcial y que, ocasionalmente, necesitan recurrir a herramientas externas para obtener la visibilidad necesaria. Cuatro encuestados (20%) evaluaron la observabilidad como totalmente suficiente, mientras que dos (10%) la consideraron limitada. Los principales puntos de fricción citados fueron la descentralización de logs y la latencia entre las capas de abstracción. Un encuestado señaló que la descentralización y la escasez de logs dificultan la identificación de la causa raíz, mientras que otro mencionó el tiempo de respuesta entre las innumerables capas y abstracciones de Fury como un desafío recurrente. Estos hallazgos sugieren la necesidad de evolución del rastreo distribuido (distributed tracing) en la plataforma, una brecha que herramientas como OpenTelemetry podrían abordar para mejorar la capacidad de diagnóstico.

Las métricas consideradas vitales por los encuestados para garantizar la salud de las aplicaciones en el ecosistema Fury se alinean con el framework de SRE de Google (Beyer et al., 2016). La Tasa de Errores fue citada por 18 de los 20 encuestados (90%), la Latencia por 17 (85%), el Tráfico por 15 (75%) y la Saturación por 12 (60%). Estas métricas están directamente correlacionadas con los pilares de SRE de Errores, Latencia/Duración, Tráfico/Tasa y Saturación, respectivamente. La alta frecuencia de mención de estas métricas por los profesionales refuerza la importancia de un monitoreo continuo y exhaustivo para el mantenimiento de la alta disponibilidad y para la rápida detección y resolución de incidentes en el entorno de microsservicios de Mercado Libre.

Discusión integrada de los hallazgos

Los hallazgos de esta investigación establecen un diálogo productivo entre la teoría y la práctica de la ingeniería de software. La confirmación de que los patrones de resiliencia descritos en la literatura, como circuit breaker, retry, bulkheads y rate limiting, están presentes y son utilizados activamente en la plataforma Fury, percibidos espontáneamente por los profesionales, valida la premisa teórica de que estos patrones son suficientemente maduros para ser incorporados en plataformas de producción a gran escala. La puntuación media de 4,6 en la evaluación comparativa de la facilidad de implementación de alta disponibilidad en Fury, en contraste con la construcción desde cero, corrobora la tesis de Skelton y Pais (2019) sobre la reducción de la carga cognitiva como un beneficio primordial de las plataformas de habilitación, permitiendo a los desarrolladores centrarse en la lógica de negocio en lugar de en la complejidad de la infraestructura.

El principal punto de tensión identificado, la insuficiencia parcial de la observabilidad nativa, es consistente con lo que Majors, Fong-Jones y Miranda (2022) denominan el problema del observador. En sistemas altamente distribuidos, la observabilidad basada en métricas y logs tradicionales es necesaria, pero no suficiente; es preciso complementar con rastreo distribuido y continuous profiling para obtener visibilidad real sobre la causalidad de los incidentes. El propio Mercado Libre publicó recientemente trabajos sobre continuous profiling utilizando flamegraphs, indicando que esta brecha está siendo activamente abordada (Mercado Libre Tech, 2025), lo que demuestra el reconocimiento interno de la necesidad de mejorar en esta área para garantizar un diagnóstico más eficaz y rápido de problemas en producción.

La curva de aprendizaje identificada como un desafío técnico revela un trade-off intrínseco entre la abstracción y la autonomía diagnóstica. Forsgren, Humble y Kim (2018) describen este fenómeno como uno de los riesgos de las abstracciones de alto nivel: al eliminar la necesidad de un conocimiento técnico profundo en el día a día, las plataformas pueden crear una dependencia que se vuelve crítica en los momentos de mayor presión, como durante incidentes. Una respuesta posible a este desafío reside en programas estructurados de inmersión técnica, como game days y ejercicios de chaos engineering, que exponen periódicamente a los desarrolladores a las capas de infraestructura que normalmente no ven. Los testimonios de profesionales con más de tres años de experiencia en la plataforma demuestran una comprensión significativamente más rica de los mecanismos de alta disponibilidad, lo que sugiere que el tiempo de exposición reduce gradualmente este déficit diagnóstico, promoviendo una mayor capacidad de resolución de problemas complejos.

Desde el punto de vista de las disciplinas del MBA en Ingeniería de Software de la USP/ESALQ, el caso de Fury ofrece ejemplos concretos de la aplicación de gran parte del currículo del programa. La arquitectura limpia (Clean Architecture) y el Domain Driven Design (DDD) influyen en el diseño de los microservicios, mientras que DevOps y Kubernetes son el sustrato técnico de Fury. La observabilidad y el monitoreo sustentan la alta disponibilidad en el día a día, y la infraestructura como código hace posible el aprovisionamiento automático de ámbitos. La integración de estas disciplinas en torno a un caso concreto demuestra cómo los conocimientos adquiridos en el programa se articulan en uno de los casos más sofisticados de ingeniería de plataforma en el continente, validando la relevancia práctica y académica del estudio.

En resumen, la plataforma Fury de Mercado Libre demuestra ser un modelo ejemplar de Internal Developer Platform, combinando prácticas de DevOps, arquitectura de microservicios y estrategia multicloud para alcanzar alta disponibilidad en una escala operativa compleja. Los resultados de la investigación confirman la eficacia de la abstracción de infraestructura y la automatización de pipelines en la reducción de la carga cognitiva de los desarrolladores, mientras que la identificación de lagunas en la observabilidad nativa apunta a áreas de mejora continua. Esta visión sistémica de la disponibilidad, que integra resiliencia en infraestructura, despliegue y aplicación, es una contribución relevante para la literatura sobre IDPs, respondiendo a la cuestión central de la investigación sobre cómo una plataforma interna de desarrollo logra garantizar alta disponibilidad a escala de decenas de miles de microservicios, manteniendo la productividad de miles de ingenieros.

4. Conclusión

Este estudio investigó cómo la plataforma interna de desarrollo Fury, de Mercado Livre, garantiza alta disponibilidad en un ecosistema de decenas de miles de microservicios, al mismo tiempo que sustenta la productividad de sus ingenieros. Se verificó que la plataforma redujo significativamente la carga cognitiva de los equipos de desarrollo, mediante la abstracción de capas de infraestructura, la automatización de pipelines de integración y entrega continuas, y la oferta de estrategias de deploy como blue-green con rollback inmediato. Los patrones de resiliencia, como circuit breaker, retry con backoff exponencial, bulkheads y rate limiting, fueron identificados como primitivas nativas y eficaces, con los profesionales evaluando la facilidad de implementación de alta disponibilidad en Fury con una media de 4,6 en una escala de 1 a 5. Sin embargo, la observabilidad nativa fue percibida como solo parcialmente suficiente por la mayoría de los respondientes, apuntando a la necesidad de un mejoramiento en el diagnóstico de incidentes en entornos distribuidos. La principal contribución de este trabajo reside en demostrar que el modelo de Internal Developer Platform adoptado por Mercado Livre es un ejemplo práctico y robusto de cómo las prácticas de DevOps, microservicios y multicloud pueden ser integradas para sustentar una disponibilidad elevada en escenarios de alta complejidad operacional, ofreciendo una visión sistémica de la resiliencia que enriquece la literatura sobre IDPs.

A pesar de los hallazgos relevantes, el estudio presenta limitaciones inherentes a su diseño metodológico. El levantamiento de campo, realizado con 20 profesionales, restringe la generalización estadística de los resultados. Adicionalmente, la dependencia de publicaciones técnicas de la propia empresa puede introducir un sesgo de selección positiva en el análisis. Para estudios futuros, se sugiere la realización de análisis comparativos entre Fury y otras Plataformas de Desarrollo Interno, como Backstage y Cortex, con el fin de identificar mejores prácticas y puntos de divergencia. También se recomienda una investigación cuantitativa del impacto de las estrategias de despliegue sobre métricas DORA, como el tiempo de entrega (lead time) y la frecuencia de despliegue, y la exploración del potencial de la inteligencia artificial generativa en la automatización de patrones de resiliencia en plataformas internas de desarrollo, con el objetivo de optimizar aún más el mantenimiento de la alta disponibilidad.

Referencias Bibliográficas

Amazon Web Services. 2023. Exponential Backoff and Jitter. AWS Architecture Blog. Disponível em: https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/. Acesso em: 10 fev. 2026.

Bardin, L. 2016. Análise de conteúdo. Edições 70, São Paulo, SP, Brasil.

Beyer, B.; Jones, C.; Petoff, J.; Murphy, N. R. 2016. Site Reliability Engineering: How Google Runs Production Systems. O’Reilly Media, Sebastopol, CA, USA.

Brasil. 2016. Conselho Nacional de Saúde [CNS]. Resolução CNS nº 510. Normas aplicáveis a pesquisas em Ciências Humanas e Sociais. Disponível em: https://conselho.saude.gov.br. Acesso em: 22 fev. 2026.

Brewer, E. A. 2000. Towards robust distributed systems. In: Annual ACM Symposium on Principles of Distributed Computing, 19., Portland. Anais… ACM, New York, NY, USA.

Carvalho, R. F. 2024. Sim, 30 mil deploys por dia. E não, não é no Vale do Silício. LinkedIn. Disponível em: https://linkedin.com. Acesso em: 10 mar. 2026.

Forsgren,

Artículo originario del Trabajo de Conclusión de Curso de la Especialización en Ingeniería de Software del MBA USP/Esalq

Para saber más sobre el curso, haga clic aquí y acceda a la plataforma MBX Academy