Mercado Envios: from a single MySQL for Latin America to cells

01 · CONTEXT

One database for the whole region

The inventory system of Mercado Envíos, from Mercado Libre, ran on what the company describes as its second-largest MySQL instance. Every inbound, outbound, reservation, and logistics movement depended on a single database that could no longer scale.

The initial architecture was simple: several inventory services connected to a single MySQL cluster. That cluster handled stock availability per fulfillment center, reservations for fulfillment shipments, and logistics movements between warehouses, sellers, and destinations.

1. API clients call the inventory services.

2. All inventory services converge on a single MySQL cluster.

3. With this design, a single failure could affect operations in several countries in the region.

According to the post, the latency of critical operations had been rising, and the question became what to do when vertical scaling is no longer an option.

02 · WHY CELLS

No bigger flavor and no reflexive microservices

For years, vertical scaling solved the problems; in the end, there were no larger flavors available and depending on a single MySQL instance became a systemic risk.

Instead of splitting everything into microservices, the team weighed that multiplying network hops or points of failure would make domain requirements such as extremely low latency even under peak load and strong inventory consistency harder to meet. So they kept an intentional monolith at the core of the system.

03 · THE ARCHITECTURE

Cells by country group, writes separated from reads

Cell-based architecture is conceptually similar to the watertight compartments of a ship: each cell operates autonomously, with its own compute, database, and traffic. If one cell fails, the others keep serving requests. This isolation reduces the blast radius.

The model introduced two layers of segregation. In the first, countries were grouped into three cells. In the second, flows were split: strictly consistent, business-critical writes on one side, and more flexible reads, backed by replicas and cache, on the other.

1. Clients reach a traffic layer that sits in front of the cells.

2. The traffic layer is connected to each cell's service.

3. Each cell has its own service and database.

4. If one cell fails, the others keep serving requests.

Implementing cells is also an operational challenge. Fury, Mercado Libre's internal development platform, made it possible to create each cell's services and databases with consistent standards and to run independent deploy pipelines per cell.

04 · ROUTING

When the API has no cell key

When designing the routing, the team saw that several APIs had no natural key identifying which cell an entity belonged to. Creating a new attribute would break compatibility with existing clients and require coordinating changes with dozens of teams and services.

The way out was to use two strategies. For legacy entities, a backward-compatible routing fallback; for new data, a deterministic ID strategy.

1. The client makes the same request as always, with no changes.

2. The traffic layer forwards the request to all cells.

3. The cell that holds the entity responds.

4. If all cells return 404, the resource really does not exist.

05 · IDS AS KEY

ID ranges per cell

The broadcast solved the problem of legacy records, but new entities called for deterministic routing. The IDs got in the way: they were public and part of old API contracts, they were sequential and generated by a single MySQL instance, and they had no embedded meaning. This brought the risk of ID collisions between cells if two primaries generated overlapping numbers.

The solution was to give each cell an exclusive range of IDs. A new entity created in a cell gets an ID that never collides with another cell's, the IDs keep the original format, and the ID itself becomes the routing key.

06 · MIGRATION AND RESULT

Migrating tens of terabytes without stopping logistics

The team migrated tens of terabytes to three independent cells. Reads continued without interruption and writes were paused only for a brief, controlled window. The playbook for each window was to copy the database to the destination cell, pause writes for a short time, and keep reads on the original database.

Because most flows are asynchronous, the short write pause had minimal impact on end customers. After the cell received its data, it went live gradually: first they turned on reads and validated critical flows, then they enabled writes, protected against contamination between cells. After validation, read traffic was shifted to the new cell with no downtime.

1. Writes go to the cell's primary, where they must be strictly consistent.

2. Reads, which are more flexible, are backed by replicas and cache.

3. The fully managed SQL service brought replication with consistency guarantees under 100 ms.

4. With replicas serving reads, reads on the primary were eliminated.

One year after the migration, p95/p99 latency had dropped by about 70%, the recurring degradation caused by backup windows was eliminated, and the team went from scaling one giant database to scaling only the cells that need it.