# Mercado Libre Tech Experiencias y reflexiones del equipo de Tech - Medium This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Continuous profiling at Mercado Libre: Turning flamegraphs into fixes DevFeed: [Continuous profiling at Mercado Libre: Turning flamegraphs into fixes]() Original publisher: [Read original article]() Author: Elton Hoffmann Published: 2026-03-11T01:27:33Z Content type: article Language: en Sources: [Mercado Libre Tech]() Topics: [observability](), [Tooling](), [Microservices](), [Latency](), [systems]() Tags: [ai](), [article](), [efficiency](), [end-user-experience](), [flamegraph](), [garbage-collection](), [latency](), [memory](), [microservices](), [observability](), [performance](), [performance-engineering](), [platform-engineering](), [profiling](), [uptime]() ### AI overview Mercado Libre describes building a continuous profiling platform for about 35,000 microservices. The platform treats profiling as an observability signal alongside metrics, logs, and traces, with the goal of helping teams detect performance issues and automate fixes for certain issue classes. ### Source excerpt We continue our series on Performance Engineering at Mercado Libre. In previous articles, we discussed how we crafted an observability culture across the company, how performance relates to other observability signals, and how the Performance Engineering team partners with Business Units to enhance platform efficiency. Today, we'll show how we built a continuous profiling platform for 35,000 microservices and how we started turning profiles into automated fixes. Context Our goal in the Performance Engineering team is threefold: to ensure uptime; to improve the end-user experience by reducing latency; to reduce computing costs. As a cross-functional team, we usually work with application owners to achieve these goals. In our two years of existence, our joint efforts have taken us through countless incidents and bottlenecks. Each problem is unique, but over time, we've seen some common patterns: high memory allocation, lack of garbage collection (GC) tuning, thread pool saturation, blocking I/O, and heavy workloads processing repeated tasks. Image 1: Typical flamegraph of high CPU usage replacing string patterns Trained eyes spot these signals quickly. But two eyeballs won't scale to thousands of services. Mercado Libre is an ever-growing company, with about 35,000 microservices, 30,000 deploys per day, and more than 16,000 people in IT roles. What are the odds that a performance issue found on one microservice doesn't exist in another? Or at least a similar issue? We often encounter systems with issues that are easy to fix but hard to detect (unless you have the right tools). It became clear we had to scale. We needed a platform-level solution that would let teams self-diagnose and self-tune. By the end of this article, you'll see how we built that and how we now automate both detection and fixes for certain classes of issues. Continuous profiling After setting our goal to improve performance tooling, we developed our own continuous profiling solution. Why profiling, ## Mutation testing at Mercado Libre: From pilot to everyday guardrail DevFeed: [Mutation testing at Mercado Libre: From pilot to everyday guardrail]() Original publisher: [Read original article]() Author: Luram Archanjo Published: 2026-01-14T12:19:03Z Content type: article Language: en Sources: [Mercado Libre Tech]() Topics: [mutation-testing](), [Testing](), [GitHub](), [Pull Request](), [test-coverage]() Tags: [ci-cd-pipeline](), [code-quality](), [github](), [github-action](), [mutation-testing](), [pull-requests](), [software-engineering](), [software-quality-testing](), [test-coverage](), [testing]() ### AI overview Mercado Envíos integrated mutation testing into Mercado Libre's Fury pipelines using a multi-stack GitHub Action, delta-first execution focused on modified code, and gradual team-level gates. The article explains how this approach supplements coverage by identifying weak test assertions and aims to improve pull request quality and reduce regressions. ### Source excerpt Beyond coverage: How we integrated mutation testing into Fury pipelines and turned it into an actionable quality indicator for teams At Mercado Envíos (ME), we saw that high test coverage didn't always prevent regressions -- pull requests (PRs) were green, but we still broke production. In this article, we share how we brought mutation testing into our pipelines on Fury, our internal developer platform (IDP). We used a single multi-stack GitHub Action, a delta-first approach, and gradual team-level gates. We walk through the design decisions, challenges, and lessons learned that helped us turn this technique into an everyday guardrail that improves test effectiveness and PR quality. Introduction: Green PR, still an incident Friday, end of the day. You've got a green PR, pipelines are passing, and coverage looks great. You merge with confidence. On Monday, production goes down because of an edge case no one asserted. Sounds familiar? Same here. Coverage tells us what runs, not whether tests fail where they should. You can have 95-100% line coverage and still let a subtle regression slip -- a slightly wrong if condition, an unexpected default value, a branch with no assertions. That's where mutation testing comes in. Instead of assuming tests are good just because they pass, you intentionally introduce small code changes (mutants) and check whether the test suite kills them. In mutation testing, "killing a mutant" means your test suite fails when run on the mutated code, proving it can detect the injected defect. If mutants survive, you get a concrete indicator of weak assertions exactly in the area you're changing. At Mercado Envíos (ME), we moved from a one-off experiment to making mutation testing part of teams' daily flow. We integrated it into our standard pipelines on Fury, Mercado Libre's internal developer platform. We did it without breaking delivery: a single, multi-stack GitHub Action; delta-first execution focused on modified code; and team-level gates with ## Segmented models for personal income estimation at Mercado Libre DevFeed: [Segmented models for personal income estimation at Mercado Libre]() Original publisher: [Read original article]() Author: Samuel Vazquez Published: 2026-01-08T20:44:23Z Content type: article Language: en Sources: [Mercado Libre Tech]() Topics: [data](), [personalization](), [datasets](), [big-data]() Tags: [big-data](), [business](), [classification](), [data](), [dataset](), [estimations](), [personal-income](), [personalization](), [regression]() ### AI overview Mercado Libre describes a "silver shotgun" approach for heterogeneous real-world data: segmenting data across contexts, training specialized models for each segment, and combining their predictions. The article presents personal income estimation as an application supporting more personalized financial products and discusses how geographic scale changes the importance of features such as home GPS location. ### Source excerpt Before we dive in, let's give a huge shout-out to Julio Avila Torreblanca and Alejandro Hernandez Cuevas for their exceptional work in developing this system. Thanks also to Enrique Miranda for reviewing the text and providing valuable feedback. Introduction Real-world data is rarely homogeneous. The same feature can mean different things depending on the city, neighborhood, urban density, or user segment. When we force a single global model to explain all those regimes, we usually pay with lower performance. At Mercado Libre, we take a different approach: instead of looking for a "silver bullet," we use a "silver shotgun." This pattern segments the data in several ways, trains specialized models per segment, and combines their predictions into a single estimate. Motivation: Financial inclusion is a significant opportunity In Mexico, only 63% of adults have a formal bank account, only 37% have a credit product, and less than 16% have a bank credit card [1]. About 45% of employed people have a formal source of income, while the rest work in the informal sector [2]. This gap presents a great opportunity for Mercado Libre to enter a growing market. Hyper-personalization is key to our mission to democratize financial inclusion across Latin America (LatAM). To offer great credit products, such as credit cards, we need a reliable estimate of a person's income. Big data, big problems Imagine we want to build a personal income estimation model for people visiting a very small local park. Every day, our dataset would grow by a few hundred entries for children playing, people exercising, and dog walkers, among other activities. Because people in the park live just a few blocks away, home location would have a limited effect (same neighborhood means low GPS variance). The features with the biggest impact on estimated income would likely be age and occupation. If we scale the problem to an entire city, home GPS location will have a bigger effect on the estimate. Each neighborho ## Security at scale: Preventing thousands of vulnerabilities without developer friction DevFeed: [Security at scale: Preventing thousands of vulnerabilities without developer friction]() Original publisher: [Read original article]() Author: Rodrigo Fernandez Apas Published: 2026-01-06T13:28:53Z Content type: article Language: en Sources: [Mercado Libre Tech]() Topics: [Security](), [Vulnerabilities](), [Application Security](), [Microservices](), [Architecture & Design]() Tags: [application-security](), [developer](), [framework](), [javascript](), [microservices](), [paved-road](), [sast](), [security](), [vulnerabilities](), [vulnerability]() ### AI overview Mercado Libre describes centralizing security protections in development frameworks and platform layers across an environment of around 20,000 developers and 35,000 microservices. The company reports that about 95% of SSRF, XSS, and CSRF vulnerability reports are now unexploitable without extra developer work. ### Source excerpt At Mercado Libre's scale, with around 20,000 developers and 35,000 microservices, security can't depend on every developer remembering flags, settings, or patterns. That approach simply doesn't scale. To tackle this, over the past few years, we've centralized our defenses within our development frameworks (such as HTTP clients and frontend frameworks) and underlying platform layers (like the HTTP routing layer). This strategy has let us achieve broad protection against common vulnerabilities such as SSRF (Server-Side Request Forgery), XSS (Cross-Site Scripting), and CSRF (Cross-Site Request Forgery). As a result, about 95% of these types of vulnerability reports are now unexploitable, without extra work from developers. In this post, we'll share our strategy, development pipeline, case studies, and key learnings from rolling out these protections. From "shift left" to "paved road"The root of the issue Many developer tools and APIs aren't designed with security in mind. For example, Java's `DocumentBuilderFactory` for XML parsing is, by default, vulnerable to XML External Entity (XXE) attacks. Preventing XXE requires configuring several additional settings: That's quite a lot to remember! Expecting every developer to recall and apply all these configurations at every stage is a heavy burden. On the other hand, Golang's XML package makes XXE vulnerabilities much less likely. You really need to make an effort to be vulnerable to XXE. You can use it without worrying about adding extra settings. These examples highlight the complex reality developers face: Unexpected insecurity: It's really easy to burn yourself without realizing it. Choice overload: On top of development and design choices, you also have to make the right security decisions. Shifting responsibilities: Developers often get blamed for insecure choices, even when these could be addressed by the platform. Additionally, common security practices pose their own challenges: In our complex environment, SAST (St ## 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 ## Scaling Kubernetes at Mercado Libre with Karpenter and GitOps DevFeed: [Scaling Kubernetes at Mercado Libre with Karpenter and GitOps]() Original publisher: [Read original article]() Author: Juliano Marcos Martins Published: 2025-10-28T13:10:37Z Content type: article Language: en Sources: [Mercado Libre Tech]() Topics: [GitOps](), [Kubernetes](), [Automation](), [Provisioning](), [Cloud Native Operations](), [Infrastructure as code](), [Microservice]() Tags: [automation](), [code](), [devops](), [gitops](), [infrastructure-as-code](), [kubernetes](), [microservices](), [multi-cloud](), [nodepool](), [provisioning](), [scalability]() ### AI overview Mercado Libre describes how it uses Kubernetes, Karpenter, and GitOps to manage a large multi-cloud environment. The article explains how declarative automation and Karpenter's on-demand node provisioning address workload orchestration, capacity alignment, standardization, and operational scale. ### Source excerpt Mercado Libre, Latin America's largest digital ecosystem, runs one of the most demanding and scalable infrastructures in the Southern Hemisphere. Our operation at scale 35,000 active microservices Over 20,000 technology professionals Approximately 30,000 daily deployments Around 120,000 pull requests per day Traffic peaks of 15 million requests per second In this fast-paced environment, efficient workload orchestration across multiple cloud providers is crucial. Kubernetes has become our standard for container management and is the foundation of our multi-cloud strategy, powering our internal compute engine. You can see more details here. This article explores how we've used Karpenter and GitOps to evolve our ecosystem, achieving automated provisioning, declarative governance, and large-scale cloud-native operations. The challenge of scale With tens of thousands of microservices, ticket-driven workflows and manual changes quickly became bottlenecks, slowing delivery and increasing operational risk. Even with the evolution of Infrastructure as Code (IaC), new challenges emerged: Explosive diversity of templates and pipelines State drift and lack of standardization Overloaded Platform/DevOps teams with repetitive requests In response, we evolved toward declarative, auditable, and fully automated practices, guided by GitOps, continuous automation, and internal infrastructure abstractions. Karpenter: What it is and why it changed the game Karpenter is an open-source, Kubernetes-native provisioning engine designed to deliver automatic scalability, cost optimization, and high flexibility in managing a cluster's data plane (compute nodes). How it works at a high level Monitors the Kubernetes scheduler for pending pods caused by insufficient compute resources. Analyzes each workload's requirements (CPU, memory, architecture, affinities, labels, tolerations, and more). Provisions, scales, or terminates nodes on demand, automatically selecting the ideal instance type, profile ## How the Fury ecosystem manages high-frequency deployments with automation, monitoring, and resilience DevFeed: [How the Fury ecosystem manages high-frequency deployments with automation, monitoring, and resilience]() Original publisher: [Read original article]() Author: Juan José Orjuela Published: 2025-10-21T13:12:29Z Content type: tutorial Language: en Sources: [Mercado Libre Tech]() Topics: [Deployment](), [Deployment Strategies](), [Automation](), [Resilience](), [configuration](), [Environment Variables]() Tags: [architecture](), [automation](), [configuration](), [continuous-deployment](), [deployment](), [deployment-strategies](), [devops](), [environment-variables](), [metrics](), [on-call](), [optimization](), [resilience](), [scalability](), [vulnerabilities]() ### AI overview This article explains how the Fury ecosystem defines and manages deployments at high frequency. It covers deployment strategies, configuration changes, automatic redeployments, testing, monitoring, alerts, metrics, and on-call practices intended to maintain operational stability. ### Source excerpt "How do you manage to perform 30.000 deployments a day and still operate normally?" For many, that number sounds simply unattainable. Deploying thousands of times a day suggests chaos, constant risk, and an operation that's hard to sustain. But the reality is different: not only do we make it possible -- we do it with control, resilience, and full visibility. It's not magic or luck. It's about a deployment ecosystem built to scale, with robust processes, smart automation, and practices that let us maintain stability even with frequent changes. +750K deployments in July 2025, broken down by deployment strategy. In this article, we'll explain how our model works: what we consider a deployment, how our system is structured, what tools we use to monitor operational health, and how we respond to alerts and failures -- whether they happen in test environments or in the most critical areas of the business. Yes, we'll also cover alerts, metrics, and on-call rotations -- and why they're essential to maintaining a continuous and reliable deployment model at this scale. General outline of a deployment in the Fury ecosystem.What do we consider a deployment? In Fury, a deployment isn't just about pushing new code. We consider a deployment to be any action that updates the state of an application in a given environment. For example: Deploying a new code change to the platform using any of our supported strategies, such as Blue-Green, Canary-Safe, Rolling Update, or All-In. Updating environment variables or configuration properties: any change to these parameters requires a deployment, as it involves recreating the application with the new active configuration. Automatic re-deployments: these can be triggered not only due to detected vulnerabilities but also due to optimization opportunities that help reduce computing resource usage and operational costs. Running validations or tests in test environments before promoting changes to production. Supported deployment strategies Our plat ## How we are using AI in Mercado Libre's accessibility team DevFeed: [How we are using AI in Mercado Libre's accessibility team]() Original publisher: [Read original article]() Author: Martín Di Luzio Published: 2025-10-08T12:58:25Z Content type: article Language: en Sources: [Mercado Libre Tech]() Topics: [Accessibility](), [Artificial Intelligence](), [Large Language Model](), [Retrieval Augmented Generation (RAG)](), [Automation](), [Design system]() Tags: [accessibility](), [ai](), [automation](), [developers](), [large-language-model](), [retrieval-augmented-generation-rag](), [web-content-accessibility-guidelines]() ### AI overview Mercado Libre's accessibility team is exploring AI to support designers and developers, automate tasks, provide immediate answers, and encourage collective learning. Its A11Y assistant uses an LLM with Retrieval-Augmented Generation to answer questions using internal documentation, training materials, historical queries, accessibility tickets, and design-system resources. AI also adds contextual explanations and recommendations to accessibility audit tickets. ### Source excerpt AI isn't here to replace accessibility work -- it's here to make it stronger. Today, our accessibility team faces a challenge: supporting hundreds of designers and developers with questions, reviews, and continuous improvements. To scale this impact, we're exploring how artificial intelligence (AI) can help us automate tasks, provide immediate answers, and foster collective learning. That's why we've launched several initiatives to speed up work, increase independence, and strengthen execution capacity. Note: In many of these initiatives, we rely on automatization tools available in our internal development ecosystem, Fury. The A11Y assistant for everyday workImage 1: Automation flow that integrates different nodes, from the user's question to obtaining relevant information, processing it, and providing an answer.How does it work? This assistant: Activates when mentioned in the support channel. Processes both messages and screen images. Consults internal documentation, training materials, historical queries, previously reported accessibility tickets, and our design system. Uses a large language model (LLM) with Retrieval-Augmented Generation (RAG) to deliver reliable answers. The result: contextualized responses grounded in internal resources and standards. From the query initiation to gathering additional context, and finally to delivering a response backed by verified information, the entire pipeline is crucial. This approach helps avoid "hallucinations" (invented or incorrect answers) and ensures the A11Y assistant stays focused on trusted resources. Thus, it provides solutions and resources that are not only accurate but also directly applicable and aligned with Mercado Libre's internal accessibility standards and tools. Understanding problems better to deliver better solutions One of our biggest learnings is that teams need information that's clear and easy to understand -- not just technical reports. In manual accessibility audits, we provide technical details s ## 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 ## Mastering Entropy: How Mercado Libre captures Millions of Users' Experiences DevFeed: [Mastering Entropy: How Mercado Libre captures Millions of Users' Experiences]() Original publisher: [Read original article]() Author: Franco Bortolazzi Conte Published: 2025-08-14T14:45:10Z Content type: article Language: en Sources: [Mercado Libre Tech]() Topics: [data](), [JSON](), [Artificial Intelligence]() Tags: [analysis](), [architecture](), [big-data](), [data](), [data-analysis](), [data-science](), [governance](), [json](), [mercadolibre](), [technology]() ### AI overview Mercado Libre describes its tracking infrastructure and governance for organizing a large volume of user interaction data. The article explains that its ecosystem generates nearly 50,000 event types and more than 17 billion daily interactions, with tracking records represented in JSON. ### Source excerpt Building a Tracking Infrastructure and Governance for Flexible Information and AI-Driven Data AnalysisGrab a coffee! Let's find order for this chaos together ☕ In the world of e-commerce, every click tells a story. We want to make sure we don't miss a single one. Let's explore the product diversity of Mercado Libre's ecosystem. It is a dynamic and expansive network designed to facilitate and enhance e-commerce & payments across Latin America. At its core is the Mercado Libre Marketplace, a platform that connects millions of buyers and sellers, offering a diverse range of products. Mercado Pago offers an innovative digital payments solution, complementing the ecosystem. To support logistics, Mercado Envíos provides efficient shipping and fulfillment services. Additionally, Mercado Crédito offers financial inclusion by providing loans to businesses and empowering sellers with access to working capital. We can also mention Mercado Play as a content platform, Mercado Ads to connect buyers to sellers or some newer players like the crypto world. Together, these interconnected services create a robust and user-friendly ecosystem, generating a huge amount of data that we collect to enhance our users' experience. The scale is truly remarkable: our platform processes nearly 50,000 distinct event types, culminating in over 17 billion daily interactions -- representing an extraordinary 50% year-over-year growth in the last years. This data deluge presents both unprecedented challenges and opportunities for creating meaningful insights. Then... how do we efficiently organize and manage this diversity and quantity of events?What is an "event" in our context? 🔍 In our ecosystem, we call it a track. We deliberately place the user at the heart of the decision-making process to enrich their experience. This approach directly embodies one of our core cultural principles: "We create value for our users". Technically, the essential form of tracks is a representation in JSON (JavaScript Obj