# From a single point of failure to a cell-based architecture: How we scaled Mercado Envíos' stock...

DevFeed: [From a single point of failure to a cell-based architecture: How we scaled Mercado Envíos' stock...](<https://devfeed.tech/articles/from-a-single-point-of-failure-to-a-cell-based-architecture-how-we-scaled-mercado-envios-stock-22551.md>)

Original publisher: [Read original article](<https://medium.com/mercadolibre-tech/from-a-single-point-of-failure-to-a-cell-based-architecture-how-we-scaled-mercado-env%C3%ADos-stock-528f581fb71b?source=rss----5011f85401f0---4>)

Author: Rafael Silvestri

Published: 2025-12-29T21:09:09Z

Content type: article

Language: en

Sources: [Mercado Libre Tech](<https://devfeed.tech/sources/mercado-libre-tech.md>)

Topics: [distributed-systems](<https://devfeed.tech/topics/distributed-systems.md>), [Architecture & Design](<https://devfeed.tech/topics/architecture-design.md>), [Scalability](<https://devfeed.tech/topics/scalability.md>), [migration](<https://devfeed.tech/topics/migration.md>), [MySQL](<https://devfeed.tech/topics/mysql.md>), [Resilience](<https://devfeed.tech/topics/resilience.md>)

Tags: [architecture](<https://devfeed.tech/tags/architecture.md>), [cell-based-architecture](<https://devfeed.tech/tags/cell-based-architecture.md>), [database](<https://devfeed.tech/tags/database.md>), [database-scalability](<https://devfeed.tech/tags/database-scalability.md>), [distributed-systems](<https://devfeed.tech/tags/distributed-systems.md>), [fury](<https://devfeed.tech/tags/fury.md>), [internaldeveloperplatform](<https://devfeed.tech/tags/internaldeveloperplatform.md>), [migration](<https://devfeed.tech/tags/migration.md>), [outages](<https://devfeed.tech/tags/outages.md>), [resilience](<https://devfeed.tech/tags/resilience.md>), [scalability](<https://devfeed.tech/tags/scalability.md>), [software-architecture](<https://devfeed.tech/tags/software-architecture.md>)

## AI overview

This article explains how Mercado Libre migrated Mercado Envíos' consolidated MySQL-based stock system into independent cells using a cell-based architecture and Fury. The migration was intended to isolate failures, reduce systemic risk, and provide more predictable scalability after the regional database reached its vertical-scaling and operational limits.

## Source excerpt

From a single point of failure to a cell-based architecture: How we scaled Mercado Envíos' stock system How we migrated Mercado Libre's second-largest MySQL instance into independent cells using Fury, reducing risk and achieving predictable scalability in Fulfillment. Abstract What happens when the database supporting a continent's logistics reaches its limits? We reached that point when a critical regional database, used for inventory operations across Latin America (LATAM), could no longer scale vertically. This article describes how we transitioned from that consolidated model to a cell-based architecture -- isolating failures, reducing systemic risk, and improving operational predictability -- while keeping logistics running throughout the migration. When a core system reaches its breaking point Software architecture uses patterns to prevent local failures from causing global outages. One of them is the cell-based architecture, which is conceptually similar to the naval bulkhead mechanism. Ships use watertight compartments, or bulkheads, to divide the hull into separate sections. If one compartment floods, the others remain sealed and the ship keeps moving. In distributed systems, we apply the same idea: each cell operates autonomously, with its own compute, database, and traffic. If one cell fails, the rest continue serving requests. This isolation reduces the blast radius and increases resilience. This pattern became essential at Mercado Libre when the stock system powering Mercado Envíos reached its operational limit. Every inbound, outbound, reservation, and logistics movement depended on a single database that could no longer scale. By early 2024, the question was clear: What do you do when vertical scaling is no longer an option? The problem: One database serving all of LATAM Our initial architecture was simple: multiple stock services connected to a single MySQL cluster. This cluster managed: Stock availability per Fulfillment Center Reservations for Fulfil