Mercado Livre Fury: from the Oracle monolith to about 30 thousand deploys a day

01 · CONTEXT

The 1999 Marketplace: a monolith

In 1999, Mercado Libre launched the first version of the Marketplace as a monolith. The platform had a few hundred physical servers, a single Oracle database, and a single repository, in which more than 200 developers worked every day.

1. The diagram shows users talking to a single application, which in turn talks to a single database.

2. In 1999 the Marketplace was born as a monolith: a few hundred physical servers, a single Oracle database, and a single repository, used by more than 200 developers every day.

3. Deploys were weekly and required a code freeze to hand the solution over to the quality team.

4. Because everyone touched the same codebase, changes could produce conflicting features: one worked and the others broke.

Deploys were weekly and required a code freeze to hand the solution over to the quality team. Because everyone changed the same codebase, changes could produce conflicting features.

02 · MELICLOUD

Microservices without a platform: chaotic freedom

Around 2010 the company made a critical decision: adopt a more scalable infrastructure based on microservices. The migration was to a platform called MeliCloud, which brought infrastructure as a service.

In this phase the source cites 17,500 instances. But the flexibility came at a price: teams started spending a lot of time solving production operational problems instead of improving the product, and there were substantial differences between the development, stage, and production environments.

03 · FURY

Fury: the internal platform is born in 2015

The need was to have a single place for infrastructure, build, deploy, metrics, and services, and to put an application live in three clicks. That is how Fury was born, in 2015: an in-house internal development platform (IDP) to create, deploy, manage, and monitor applications.

Creating an application already generates the repository with the team's permissions, sets up the CI/CD pipeline, and delivers scaffolding with a containerized image. To ensure reliability, critical applications are split into separate scopes, and a failure in one scope does not affect the others.

1. In the diagram, the team talks to the internal platform, which triggers the CI pipeline and the deploy orchestrator.

2. When an application is created, the platform generates the repository with the team's permissions, sets up the CI/CD pipeline, and delivers scaffolding with a containerized image.

3. The build produces an artifact, typically a Docker image, published to the internal registry; a generated version never changes again.

4. The orchestrator uses the already-built artifact and orchestrates its execution in one or more scopes, without needing to rebuild it.

5. Every significant change goes through at least one validation environment before affecting end users or critical systems.

6. The platform measures every stage of the deploy cycle; in critical production, the alert demands immediate attention, handled by on-call rotations.

The release process, in effect since 2018, runs seven quality checks over more than 26 thousand repositories; if one check fails, the whole flow is halted until it is fixed.

04 · DEPLOY

Building is one thing, deploying is another

Fury explicitly separates build, which creates the version, from deploy, which runs it. A generated version is immutable, and the same version can be deployed multiple times to different scopes or configurations, without a rebuild.

There is no single deploy approach: the strategy varies with the criticality of the scenario. Strategies that reuse existing infrastructure are fast and cheap, but hard to roll back; Blue-Green, on the other hand, which creates a new environment, is suited to production scopes that require fast recovery in case of error. The supported strategies include Blue-Green, Canary-Safe, Rolling Update, and All-In.

1. The diagram shows a traffic control that splits users between the current version and the new version.

2. In Blue-Green the new version is deployed to the passive environment without affecting real traffic; after it is validated, traffic is redirected and the switch is instantaneous.

3. In Canary the new version receives only a small share of traffic, while the rest stays on the previous version.

4. The new version is monitored in real production with real users and, if everything works as expected, traffic is gradually increased.

5. With programmable rollback, in case of failure or anomalous metrics the deploy can be reverted automatically.

Each scope is categorized by criticality level, and this classification defines the risk of any change. The platform also offers programmable rollbacks, which revert automatically in case of failure or anomalous metrics.

05 · SCALE AND OPERATIONS

The numbers, always with the year next to them

The case's numbers come from three sources from different years, which is why each one appears with its source's year.

Fury counts as a deploy any action that updates an application's state in an environment. This includes changing environment variables or configuration, and also automatic re-deploys, such as one triggered when a sidecar is updated or when monitoring suggests reducing CPU and memory. The source itself points to automation as one of the enablers of running 30 thousand deploys per day.

Os sidecars give more control over security, compliance, and NoOps in each microservice; the talk mentions a MySQL proxy, traffic middleware, and log and metrics agents. Language diversity, on the other hand, increases the complexity of operating at scale.

Each deploy step is idempotent and can be repeated without leaving the system inconsistent. Alerts from test scopes have a low-priority SLA; in critical production the alert demands immediate attention, handled by on-call rotation.