High Availability in Microservices: the Case of Mercado Livre’s Fury Platform

Thiago Veiga Lima; Vinicius Santos Andrade

DOI: 10.22167/2675-6528-202602380

Article derived from a Course Conclusion Work (TCC), with content based on the student’s original work and adapted to the editorial format of the E&S Magazine with the support of the ResumeAI tool, an artificial intelligence solution developed by Instituto Pecege for textual synthesis and organization.

Summary

The scalability and resilience of software platforms represent central challenges for technology companies operating at scale. We investigated how the internal development platform Fury, created and maintained by Mercado Livre, implemented high availability (HA) mechanisms in a microservices ecosystem encompassing over 30,000 services running on 100,000 production instances. The research combined a literature review on resilience patterns (circuit breaker, retry with exponential backoff, bulkheads, and rate limiting), documentary analysis of Mercado Livre’s technical publications, and a field survey applied to 20 engineers and tech leads who use or manage applications on the platform. The results indicated that Fury significantly reduced the cognitive load of development teams by abstracting infrastructure layers, automating continuous integration and continuous delivery (CI/CD) pipelines, and offering deployment strategies such as blue-green with immediate rollback. Native observability, however, was evaluated as only partially sufficient by the majority of respondents, highlighting a gap that the organization is addressing with integration to market tools. It was concluded that the Internal Developer Platform (IDP) model adopted by Mercado Livre is an example of how DevOps, microservices, and multicloud practices can be combined to sustain high availability in environments of high operational complexity. This systemic view of availability is a relevant contribution to the literature on IDPs.

Keywords: High Availability; DevOps; Fury; Internal Developer Platform; Microservices.

1. Introduction

The reliability of digital services is no longer a competitive differentiator but has become a basic market requirement. On e-commerce and financial services platforms operating twenty-four hours a day, seven days a week, the unavailability of a component can mean direct revenue loss, erosion of consumer trust, and, in extreme cases, regulatory impacts. This scenario underscores the critical importance of robust systems capable of maintaining continuous operation even under adverse conditions.

Mercado Livre, recognized as the largest e-commerce and financial services ecosystem in Latin America, exemplifies this challenge. With operations in eighteen countries and over one hundred million active users, its structure requires engineering teams to manage tens of thousands of interdependent microservices. These services are constantly subject to unpredictable demand peaks, especially during events like Consumer Day or Black Friday. Ensuring continuous functionality at this scale demands sophisticated mechanisms for high availability.

In this highly complex and dynamic context, the central question of this research was: how can an internal development platform ensure high availability at the scale of tens of thousands of microservices, while maintaining the productivity of over 15,000 engineers? This challenge highlights the need for systematic approaches to build resilient software platforms at an exceptional scale.

High availability (HA) is defined as the ability of a system to remain operational for a given percentage of time within a reference period, usually expressed in ‘nines’. For example, 99.9% availability equates to approximately eight hours and forty minutes of downtime per year, while 99.99% reduces this number to about fifty-two minutes (Tanenbaum and Van Steen, 2016). The theoretical foundations of HA date back to the CAP theorem, formulated by Brewer (2000) and formalized by Gilbert and Lynch (2002), which states that no distributed system can simultaneously guarantee total consistency, total availability, and network partition tolerance. High availability-oriented architectures tend to favor availability and partition tolerance, accepting eventual inconsistency, a model known as BASE (Basically Available, Soft State, Eventually Consistent). Site Reliability Engineering (SRE) has consolidated practices such as defining Service Level Objectives (SLOs), Service Level Indicators (SLIs), and error budgets, which allow balancing the speed of feature releases with maintaining service reliability (Beyer et al., 2016).

The adoption of microservices architectures has brought widely documented resilience patterns. The circuit breaker interrupts calls to failing services and returns fallback responses, preventing cascading propagation (Nygard, 2007; Fowler, 2014). Retry with exponential backoff repeats calls with increasing intervals, with added jitter to avoid the thundering herd phenomenon (Amazon Web Services, 2023). Bulkheads isolate pools of resources by dependency, and rate limiting protects services from abusive traffic spikes (Richardson, 2018). The concept of Internal Developer Platform (IDP) emerged as a response to the operational complexity of microservices environments, offering a self-service layer that allows developers to build, deploy, and monitor applications without directly interacting with the underlying infrastructure (Humanitec, 2023). The multicloud strategy, which involves the simultaneous use of providers like AWS and GCP, complements this model by increasing availability through geographic redundancy and reducing the risk of vendor lock-in (Gartner, 2022).

The relevance of the topic extends beyond the limits of the studied company, as understanding how these resilience patterns materialize on a real-use, real-scale platform is a valuable exercise for both researchers and professionals who need to make architectural decisions daily. From an academic point of view, the work is situated at the intersection of multiple disciplines explored throughout the MBA in Software Engineering at USP/ESALQ: microservices, DevOps, container orchestration with Kubernetes, observability and monitoring, infrastructure as code, and cloud computing. Thus, this work analyzed how Mercado Livre faced the challenge of high availability when building the internal Fury platform, investigating the resilience patterns employed, the results obtained in the field, and the lessons this case offers to contemporary software engineering.

2. Material and Methods

The present research was characterized, in terms of its nature, as applied, as it was oriented towards the solution of a practical problem related to the implementation of high availability in microservices environments. In terms of approach, a predominantly qualitative design was adopted, complemented by quantitative elements in the data analysis stage collected through a questionnaire. Regarding the objectives, the study was classified as exploratory-descriptive, seeking to explore the Fury platform, which has limited public documentation, and to systematically describe its resilience mechanisms (Gil, 2017).

The research strategy employed was the embedded single case study, as proposed by Yin (2015). The Fury platform, developed and maintained by Mercado Livre, constituted the primary unit of analysis. This choice was justified by the uniqueness of the case, given the absence of another internal development platform in Latin America that presents comparable scale and maturity, making it a relevant object of study for software engineering.

For data collection, three complementary sources were used, aiming at triangulation and increasing the internal validity of the research. The first source consisted of a comprehensive literature review, which included books, scientific articles, and specialized technical documentation on high availability, resilience standards, and internal development platforms.

The second data source involved the documentary analysis of technical publications released by Mercado Livre itself. Articles published on Medium Engineering (Martins, 2024), presentations given at public conferences, such as PlatformCon 2023, and open-source repositories maintained by the organization were examined. This approach allowed for an understanding of the Fury platform’s strategies and implementations based on official materials.

The third data source was a field survey, conducted by applying a structured questionnaire. This instrument was directed at professionals who use or manage applications on the Fury platform at Mercado Livre. The questionnaire sought to collect perceptions and direct information from users about the operationalization of high availability.

The data collection instrument consisted of a structured questionnaire, the full content of which is detailed in Annex A of the original work. The questionnaire was applied digitally, using the Google Forms platform, between February and April 2026. This method ensured standardization of collection and ease of access for participants.

Twenty Mercado Livre professionals, including software engineers and tech leads or project leaders, participated in the field survey. The questionnaire consisted of seven questions that addressed aspects such as the profile and experience of the respondents with the Fury platform, the identified resilience patterns, the evaluation of the ease of implementing high availability compared to building from scratch, the technical challenges faced, the sufficiency of native observability tools, and the metrics considered vital for application health.

The analysis of the collected data was carried out in two stages. Quantitative data, obtained from the closed-ended questions of the questionnaire, were subjected to simple descriptive statistics, with the calculation of absolute and percentage frequency. This approach allowed for the quantification of response distribution and the identification of general trends.

The qualitative data, from the open-ended questionnaire responses, were subjected to thematic content analysis, according to Bardin’s methodology (2016). Through this technique, emergent categories were identified from the recurrence of themes and concepts in the participants’ responses. Triangulation among the three data sources — literature review, documentary analysis, and field survey — was employed to strengthen the internal validity of the research conclusions.

Ethical considerations were rigorously observed during all stages of the research. The study was conducted in accordance with Resolution CNS No. 510, of April 2016, from the National Health Council. The research fell under the exceptions of items I and VII of Article 1 of the aforementioned resolution, as it used anonymously collected information in a professional environment, ensuring the privacy and confidentiality of the participants.

3. Results and Discussion

The investigation into Mercado Livre’s Fury platform revealed a robust set of strategies and mechanisms that support high availability in a large-scale microservices ecosystem. The findings indicate that the platform acts as an effective abstraction layer, reducing developers’ cognitive load and automating critical infrastructure and deployment processes. The research combined the analysis of the company’s technical publications with a field survey of 20 engineers and tech leads, providing a multifaceted view of the implementation and perception of resilience patterns. The results confirm the relevance of the Internal Developer Platform (IDP) model for managing the operational complexity inherent in distributed environments, while also pointing to persistent challenges, especially in the field of native observability.

History and creation context of the Fury

The evolution of the Fury platform is intrinsically linked to the exponential growth of Mercado Livre, which in 1999 operated on a monolithic architecture with hundreds of servers and a single database. This structure, although initially functional, became a severe bottleneck, resulting in weekly deploys with code freezes, slow tests, and team conflicts (Martins, 2024). The migration to microservices around 2010 and the launch of MeliCloud, the first internal infrastructure as a service, represented a significant advancement, with over 1,400 instances deployed daily and 17,500 managed instances. However, MeliCloud introduced excessive heterogeneity, where each team defined its own infrastructure, hindering consistency and standardization.

This experience led to the formulation of a central principle for Fury’s design: allowing a developer to have an application in production with just three clicks. Launched in 2015, the internal development platform Fury materialized this principle, seeking to abstract infrastructure complexity and standardize the software lifecycle. This approach aimed not only to increase engineers’ productivity but also to ensure that high availability mechanisms were intrinsically incorporated into the development and operation process, facilitating the scalability and resilience of the microservices ecosystem.

Architecture and main components

Fury operates as a comprehensive Internal Developer Platform (IDP), abstracting the entire application creation, configuration, deployment, and monitoring chain. Interaction with the platform is done through a web interface and a Command Line Interface (CLI), simplifying access and management for developers. The central organizational concept is “Scope,” representing a simplified execution environment within a cloud provider, whether for development, staging, or production. When creating a scope, Fury automatically provisions essential components like load balancers, autoscaling groups, and instances, in addition to configuring logs, metrics, and alerts, all transparently for the user.

The platform acts as a crucial abstraction layer between developer applications and external services, including providers like AWS, GCP, and Mercado Livre’s on-premises infrastructure. Applications do not communicate directly with these cloud services; instead, an anti-corruption layer is employed to prevent lock-in, facilitate version updates, and allow for provider swapping without requiring changes to the application code (Martins, 2024b). This simplified yet powerful architecture is fundamental for maintaining high availability, as it isolates applications from the underlying infrastructure complexity.

The Release Process, implemented since 2018, is a vital component of Fury, managing over 26,000 repositories and automatically executing seven quality validations for each integration. These validations include dependency checks, branching model, test coverage, and hardcoded credential analysis, ensuring code integrity and security. In 2024, the platform was already processing over 30,000 deploys per day through this pipeline (Carvalho, 2024), demonstrating large-scale continuous delivery capability. The platform’s operational indicators in 2024 are notable, with over 30,000 microservices in production, over 100,000 production instances, over 15,000 engineers using the platform, and over 26,000 managed repositories, in addition to the 30,000 daily deploys.

High availability mechanisms in Fury

High availability in Fury is not an isolated feature, but an emergent property of a systemic design that incorporates resilience across three interconnected layers: infrastructure, deploy, and application. At the infrastructure layer, automatic autoscaling is the most prominent mechanism. When a scope is created, the platform configures autoscaling groups that adjust the number of instances based on metrics such as CPU, memory, and request volume, transparently to the developer. This autoscaling management was developed internally to support a multi-vendor solution, without exclusively relying on specific cloud provider services (Martins, 2024b). Workload distribution across multiple availability zones complements autoscaling, ensuring that the failure of a datacenter does not compromise service availability.

In the deploy layer, Fury offers several strategies to ensure operational continuity during updates. Among the five available strategies (All-in, Blue-Green, Canary, Safe Deploy, and Migration), Blue-Green is the default choice for critical services. It creates a new parallel environment, gradually migrates traffic, and allows for immediate rollback without downtime. Safe Deploy is a variation that continuously monitors metrics and automates rollback decisions when anomalies are detected, reinforcing the resilience of the deployment process. These strategies are crucial for maintaining high availability, minimizing the impact of new versions.

In the application layer, widely recognized resilience patterns in the literature are made available as native platform primitives. The circuit breaker interrupts calls to failing services, returning fallback responses and preventing cascading propagation (Nygard, 2007; Fowler, 2014). Retry with exponential backoff repeats calls with increasing intervals, adding jitter to avoid the thundering herd phenomenon (Amazon Web Services, 2023). Bulkheads isolate resource pools by dependency, and rate limiting protects services from abusive traffic spikes (Richardson, 2018). The separation of critical applications into independent scopes functions as an infrastructure-level bulkhead, ensuring that problems in one scope do not affect others. These patterns, integrated into the platform, are essential for the robustness of microservices.

Observability and monitoring

Observability, defined as the ability to infer the internal state of a system from its external outputs, is an inseparable pillar of high availability. Without adequate visibility into what is happening in production, even the most sophisticated resilience designs can fail silently for long periods before being detected (Majors, Fong-Jones, and Miranda, 2022). Fury natively offers infrastructure metrics monitoring, including CPU, memory, traffic, latency, and error rates. Furthermore, the platform centralizes logs and allows alert configuration, with integrations to market tools such as DataDog, New Relic, and OpsGenie. Monitoring extends to specific business rules, such as spikes in payment processing time, providing a comprehensive view of application health.

Evolution to multicloud and GenAI

Fury’s multicloud strategy abstracts the underlying providers, such as AWS and GCP, presenting developers with a unified interface independent of the infrastructure used. This design has direct implications for high availability, as distributing workloads across distinct providers reduces the risk of an incident on a specific provider affecting the entire operation. Multicloud abstraction is enabled by the use of Kubernetes for container orchestration, Terraform for infrastructure as code provisioning, and a proprietary automation layer that incorporates Mercado Livre’s conventions and security policies. Currently, about 20% of the infrastructure still operates outside of Fury, in what is called the Off-Fury world, managed by Infrastructure as Code tools to maintain compliance and visibility (Martins, 2024b).

The next step announced by the company is the integration with generative artificial intelligence (GenAI), in partnership with OpenAI, to create disruptive solutions in the development ecosystem. This initiative aims to use AI in optimizing traffic routes, in predictive anomaly detection, and in the automatic generation of code with built-in resilience patterns. These trends align with the concept of AIOps (Artificial Intelligence for IT Operations), which seeks to automate and optimize IT operations through artificial intelligence, promising significant advances in maintaining the high availability and operational efficiency of the Fury platform.

Respondent profile

The field survey was conducted with 20 Mercado Livre professionals between February and April 2026. The majority of respondents, 16 (80%), were software engineers or developers, while 4 (20%) were tech leads or project leaders. Regarding experience with the Fury platform, the predominance of respondents with less than one year of use reflects the rapid growth of Mercado Livre’s engineering team and the continuous cycle of onboarding new employees. However, the presence of 4 (20%) professionals with more than three years of experience and 2 (10%) with experience between one and three years provided valuable insights into the platform’s evolution and challenges over time, enriching the qualitative analysis of resilience mechanisms.

Resilience patterns identified

When questioned about the most effective resilience patterns on the Fury platform, respondents could select multiple options, revealing their perception of use and the prominence of each mechanism. Retry with Backoff and Rate Limiting patterns were the most cited, mentioned by 15 out of 20 respondents, which corresponds to 75% of the mentions. Circuit Breaker was identified by 13 respondents (65%), while Bulkheads was cited by 9 (45%) and Fallback Strategies by 7 (35%). This data indicates that Retry with Backoff and Rate Limiting are the first protection mechanisms that new Fury users interact with, while Bulkheads and Fallback Strategies require greater maturity in platform usage to be fully perceived and utilized by developers.

The ease of implementing high availability in Fury, compared to building solutions from scratch, was rated an average of 4.6 on a scale of 1 to 5, where 5 represents “very easy”. Only one respondent gave a score of 3, citing difficulties in managing timeouts, while the others gave scores of 4 or 5. This general perception of high ease suggests that Fury substantially simplifies the implementation of high availability mechanisms. One respondent summarized this perception by stating that, as of the survey, the platform had ensured high availability without their team needing to take additional actions, highlighting the effectiveness of the abstraction and automation offered by Fury.

Technical challenges and observed gaps

The open-ended responses about technical challenges revealed three main categories. The first, mentioned by four respondents, was the learning curve and the need for in-depth knowledge of the ecosystem. As a proprietary platform with internal documentation, Fury presents a steep learning curve without abundant external references, unlike public cloud services such as AWS, Azure, and GCP. This knowledge isolation is a paradoxical consequence of abstraction’s success: the more the platform hides complexity, the less the developer understands what to do when problems arise, which can hinder incident resolution.

The second category of challenges was the complexity of the distributed environment. One respondent highlighted that dealing with a highly distributed environment, full of dependencies and with continuous deployments, is the biggest obstacle. Any slowness or failure in one service can trigger a cascading effect in others, evidencing that, although resilience patterns are effective, they manage the complexity inherent in distributed systems but do not completely eliminate it. The interconnection of microservices requires a deep understanding of interactions to mitigate the risks of cascading failures, even with the implementation of resilience patterns.

The third category of challenges was observability and incident diagnosis. Among the 20 respondents, 13 (65%) stated that Fury’s native visibility is only partial and that they occasionally need to resort to external tools to obtain the necessary visibility. Four respondents (20%) rated observability as fully sufficient, while two (10%) considered it limited. The main friction points cited were log decentralization and latency between abstraction layers. One respondent pointed out that log decentralization and scarcity make root cause identification difficult, while another mentioned the response time between Fury’s numerous layers and abstractions as a recurring challenge. These findings suggest the need for evolution in distributed tracing on the platform, a gap that tools like OpenTelemetry could address to improve diagnostic capabilities.

The metrics considered vital by respondents to ensure the health of applications in the Fury ecosystem align with Google’s SRE framework (Beyer et al., 2016). Error Rate was cited by 18 of the 20 respondents (90%), Latency by 17 (85%), Traffic by 15 (75%), and Saturation by 12 (60%). These metrics are directly correlated to the SRE pillars of Errors, Latency/Duration, Traffic/Rate, and Saturation, respectively. The high frequency of mention of these metrics by professionals reinforces the importance of continuous and comprehensive monitoring for maintaining high availability and for the rapid detection and resolution of incidents in Mercado Livre’s microservices environment.

Integrated discussion of findings

The findings of this research establish a productive dialogue between theory and practice in software engineering. The confirmation that the resilience patterns described in the literature, such as circuit breaker, retry, bulkheads, and rate limiting, are present and actively used in the Fury platform, spontaneously perceived by professionals, validates the theoretical premise that these patterns are mature enough to be incorporated into large-scale production platforms. The average score of 4.6 in the comparative evaluation of the ease of implementing high availability in Fury, in contrast to building from scratch, corroborates Skelton and Pais’s (2019) thesis on the reduction of cognitive load as a primary benefit of enablement platforms, allowing developers to focus on business logic rather than infrastructure complexity.

The main point of tension identified, the partial insufficiency of native observability, is consistent with what Majors, Fong-Jones, and Miranda (2022) call the observer problem. In highly distributed systems, observability based on traditional metrics and logs is necessary but not sufficient; it needs to be complemented with distributed tracing and continuous profiling to gain real visibility into the causality of incidents. Mercado Livre itself recently published work on continuous profiling using flamegraphs, indicating that this gap is being actively addressed (Mercado Libre Tech, 2025), which demonstrates internal recognition of the need for improvement in this area to ensure more effective and faster diagnosis of production problems.

The learning curve identified as a technical challenge reveals an intrinsic trade-off between abstraction and diagnostic autonomy. Forsgren, Humble, and Kim (2018) describe this phenomenon as one of the risks of high-order abstractions: by eliminating the need for deep technical knowledge in daily life, platforms can create a dependency that becomes critical in moments of greatest pressure, such as during incidents. A possible response to this challenge lies in structured technical immersion programs, such as game days and chaos engineering exercises, which periodically expose developers to the infrastructure layers they normally do not see. Testimonials from professionals with more than three years of experience on the platform demonstrate a significantly richer understanding of high-availability mechanisms, suggesting that exposure time gradually reduces this diagnostic deficit, promoting a greater capacity for solving complex problems.

From the perspective of the MBA in Software Engineering disciplines at USP/ESALQ, the Fury case offers concrete examples of the application of a large part of the program’s curriculum. Clean Architecture and Domain Driven Design (DDD) influence the design of microservices, while DevOps and Kubernetes are the technical substrate of Fury. Observability and monitoring support high availability on a daily basis, and infrastructure as code makes automatic provisioning of scopes possible. The integration of these disciplines around a concrete case demonstrates how the knowledge acquired in the program is articulated in one of the most sophisticated cases of platform engineering on the continent, validating the practical and academic relevance of the study.

In summary, Mercado Livre’s Fury platform demonstrates itself as an exemplary model of an Internal Developer Platform, combining DevOps practices, microservices architecture, and a multicloud strategy to achieve high availability on a complex operational scale. The research results confirm the effectiveness of infrastructure abstraction and pipeline automation in reducing developers’ cognitive load, while the identification of gaps in native observability points to areas for continuous improvement. This systemic view of availability, which integrates resilience in infrastructure, deployment, and application, is a relevant contribution to the literature on IDPs, answering the central research question about how an internal development platform can ensure high availability at the scale of tens of thousands of microservices, while maintaining the productivity of thousands of engineers.

4. Conclusion

This study investigated how Mercado Livre’s internal development platform, Fury, ensures high availability in an ecosystem of tens of thousands of microservices, while simultaneously sustaining the productivity of its engineers. It was found that the platform significantly reduced the cognitive load of development teams through the abstraction of infrastructure layers, the automation of continuous integration and delivery pipelines, and the offering of deploy strategies such as blue-green with immediate rollback. Resilience patterns, such as circuit breaker, retry with exponential backoff, bulkheads, and rate limiting, were identified as native and effective primitives, with professionals rating the ease of implementing high availability on Fury with an average of 4.6 on a scale of 1 to 5. However, native observability was perceived as only partially sufficient by the majority of respondents, pointing to the need for improvement in incident diagnosis in distributed environments. The main contribution of this work lies in demonstrating that the Internal Developer Platform model adopted by Mercado Livre is a practical and robust example of how DevOps, microservices, and multicloud practices can be integrated to sustain high availability in scenarios of high operational complexity, offering a systemic view of resilience that enriches the literature on IDPs.

Despite the relevant findings, the study has limitations inherent to its methodological design. The field survey, conducted with 20 professionals, restricts the statistical generalization of the results. Additionally, the reliance on the company’s own technical publications may introduce a positive selection bias in the analysis. For future studies, it is suggested to conduct comparative analyses between Fury and other Internal Developer Platforms, such as Backstage and Cortex, in order to identify best practices and points of divergence. It is also recommended a quantitative investigation of the impact of deploy strategies on DORA metrics, such as lead time and deploy frequency, and the exploration of the potential of generative artificial intelligence in automating resilience patterns in internal development platforms, aiming to further optimize the maintenance of high availability.

Bibliographic References

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,

Article originating from the Final Course Work of the Specialization in Software Engineering of the MBA USP/Esalq

To learn more about the course, click here and access the MBX Academy platform