# fury Published articles for fury. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## 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...]() Original publisher: [Read original article]() Author: Rafael Silvestri Published: 2025-12-29T21:09:09Z Content type: article Language: en Sources: [Mercado Libre Tech]() Topics: [distributed-systems](), [Architecture & Design](), [Scalability](), [migration](), [MySQL](), [Resilience]() Tags: [architecture](), [cell-based-architecture](), [database](), [database-scalability](), [distributed-systems](), [fury](), [internaldeveloperplatform](), [migration](), [outages](), [resilience](), [scalability](), [software-architecture]() ### 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 ## KVS: The key-value storage engine that powers the Fury ecosystem DevFeed: [KVS: The key-value storage engine that powers the Fury ecosystem]() Original publisher: [Read original article]() Author: Ariel Zach Published: 2025-10-01T14:09:08Z Content type: article Language: en Sources: [Mercado Libre Tech]() Topics: [NoSQL](), [Persistence](), [Scalability](), [Low Latency](), [Availability](), [Data Management]() Tags: [architecture](), [availability](), [data](), [database](), [databases](), [development](), [distributed](), [fury](), [infrastructure](), [key-value-store](), [kvs](), [low-latency](), [nosql](), [persistence](), [resilience](), [scalability](), [security](), [storage]() ### AI overview This article explains KVS, a key-value storage system in the Fury ecosystem. It describes how unique key-value pairs enable fast access, and reports that KVS supports large-scale distributed persistence with automatic scaling, low latency, availability, and recovery mechanisms. ### Source excerpt In modern software development, the efficiency, scalability, and resilience of data storage systems are critical to any platform's success. In this context, KVS (Key-Value Store) emerges as a fundamental component within the Fury ecosystem, offering a robust and flexible solution for data management. This article explores what KVS is, how it works, and why it's so important for Fury and its users. What is KVS? KVS, or Key-Value Store, is a data storage system based on the key-value paradigm. Unlike traditional relational databases, which organize data in tables and rows, KVS stores each data element as a unique key-value pair. This approach simplifies access and manipulation of information, enabling extremely fast and efficient operations. In Fury, KVS isn't just another database -- it's the fundamental engine that drives distributed, scalable, and fault-tolerant data persistence and retrieval. Currently, KVS processes over 642 million operations per minute, including 572 million reads and 70 million writes. The underlying infrastructure scales automatically and maintains low latency even under high-demand scenarios. The service is used by more than 7,600 applications within Mercado Libre (around 25% of the total), making it a key component of the ecosystem. Overall, it stores over 9 petabytes of data with mechanisms that ensure availability and recovery in case of failures. How does KVS work? Each piece of data is stored under a unique key. To retrieve or modify a value, you only need to know its key, eliminating the need for complex queries and relationships. This speeds up both read and write operations. KVS is built on top of the Fury ecosystem, which provides key guarantees such as scalability, security, and traffic control. It uses an architecture based on a fully managed NoSQL solution, designed to automatically adapt to demand. Thanks to this infrastructure, KVS inherits advanced scalability capabilities, allowing it to grow automatically and transparently, c