11 Years at MercadoLibre: Lessons in Data at Scale

The Journey: 2015-Present

MercadoLibre isn’t just Latin America’s largest e-commerce platform — it’s a complex ecosystem of marketplaces, payments (Mercado Pago), shipping (Mercado Envios), advertising, and financial services serving hundreds of millions of users across 18 countries.

I’ve spent over 11 years here, and I’m still going. I joined in 2015 when MercadoLibre acquired KPL Soluções, a Brazilian company specializing in ERP and invoice solutions for e-commerce. The acquisition was strategic: Brazil’s complex fiscal landscape required robust invoice capabilities, which became a key enabler for the Fulfillment project.

I started as a support assistant for a legacy system that would later be discontinued. Today, I’m the senior data engineer responsible for a team supporting an entire business unit — not a formal tech lead title, but the de facto leadership that comes with being the most experienced person on a team that needed to build a data foundation from scratch.

This post distills what I’ve learned building data systems at scale — lessons you can’t get from tutorials or certifications.

---

Lesson 1: Start Where You Are

From Support to Data Visualization

When I joined, I wasn’t a data engineer. I was troubleshooting legacy systems and answering support tickets. But I noticed something: I kept gravitating toward data problems.

In 2018, I started creating visualizations for my team’s KPIs. Nothing fancy — just charts that helped us understand what was happening. But those visualizations got noticed. They led to conversations. And those conversations opened doors.

The transition wasn’t clean. I didn’t follow a linear path from “support” to “analyst” to “engineer.” I took on hybrid roles, volunteered for data-adjacent projects, and learned on the job.

Lesson: You don’t need permission to start working with data. Find a problem, build something useful, and let the work speak for itself.

---

Lesson 2: Domain Knowledge Compounds

The Shift to Embedded Data Teams

When I started transitioning to data work, MercadoLibre was going through an organizational transformation that I didn’t fully appreciate at the time.

The company originally had centralized data teams — dedicated analysts and engineers who served multiple business units. But as MercadoLibre’s data-driven culture accelerated, these teams became bottlenecks. The problem wasn’t technical skill. It was domain expertise. A centralized analyst supporting five different teams couldn’t understand any of them deeply.

The solution? Embedded data capabilities within domain teams. Instead of requesting data work from a central queue, business units started building their own data competencies. My transition to Mercado Envios was part of this broader shift — the logistics team creating their own data muscle.

The Mercado Envios Years

I spent most of my career in Mercado Envios — the logistics business unit. MercadoLibre moves millions of packages daily across 18 countries. The data challenges were enormous:

• Package tracking across multiple carriers and facilities
• Delivery SLA monitoring at massive scale
• Optimization opportunities hidden in operational data

Working as an embedded data professional meant I could go deep on logistics problems. I worked in small teams of 2-3 analysts on projects ranging from data visualization to data science:

• Building dashboards for operations teams
• Creating data pipelines for logistics metrics
• Supporting data analysis for the Loyalty program

The biggest project: Hunting Inteligente — a classification model for listings and customers to optimize conversion for our fulfillment picking type. This wasn’t just a technical exercise; it required deep understanding of how the business actually worked.

Lesson: Technical skills get you in the door. Domain expertise makes you valuable. Embedded data teams work because they combine technical capability with business context. The best data engineers understand the business, not just the data.

---

Lesson 3: Observability Beats Optimization

Making the Invisible Visible

One of the most impactful things I learned in logistics: you can’t optimize what you can’t see.

Teams had data. They had dashboards. But they didn’t have visibility — a clear, holistic view of what was actually happening across the pipeline.

The most valuable work I did wasn’t building sophisticated ML models. It was building simple, clear dashboards that answered basic questions:

• Where is this package right now?
• Which routes are consistently late?
• Where are the bottlenecks?

The tech was simple: Well-modeled tables, clean transformations, and dashboards that told a story. Nothing fancy.

Lesson: You don’t need ML or real-time streaming to create value. Sometimes you just need to help people see what’s happening. Clear visibility is worth more than clever algorithms.

---

Lesson 4: Cross-Functional Alignment is the Hard Part

The Translation Problem

Here’s what no one tells you about data engineering: the technical work is the easy part.

The hard part is:

• Getting stakeholders to agree on metric definitions
• Navigating conflicting priorities between teams
• Explaining why “just add this field” isn’t simple
• Building trust with teams who depend on your systems

At MercadoLibre, I’ve worked across business units — logistics, loyalty, corporate tech. Each has its own language, priorities, and politics. The data engineers who succeed aren’t the ones with the best SQL skills. They’re the ones who can translate between business and technology.

Lesson: You’re not a “data person.” You’re a translator. If stakeholders can’t agree on a spreadsheet, they won’t agree on a database. Do the hard alignment work up front.

---

Lesson 5: Build for the Team, Not the Resume

The Current Chapter

Around two years ago, I transitioned to Internal Systems (Corporate Tech). Today, I’m the senior data engineer on a team of 4 — the only senior in a business unit that lagged in data culture.

What I inherited:

• A dozen ungoverned dashboards no one maintained
• A BigQuery sandbox no one knew the contents of
• Three junior engineers looking for direction and best practices

Our work isn’t glamorous:

• Batch pipelines that fetch data from internal databases on AWS
• Defining requirements and best practices
• Reviewing code and mentoring engineers
• Building the complex stuff when needed

But it’s foundational. Every decision we make affects how other teams access and use data. The most important skill isn’t coding — it’s judgment. Knowing when to build, when to buy, when to say no.

Lesson: Senior roles aren’t about titles. They’re about taking responsibility when someone needs to. The best data systems I’ve built are the ones my team can maintain without me.

---

What I’d Do Differently

Looking back, here’s what I’d change:

1. Document tribal knowledge earlier — We lost critical context when senior engineers left
2. Invest in data contracts sooner — Clear SLAs between teams prevent outages
3. Push back on “data-driven” cargo culting — Not every decision needs a dashboard
4. Build less, buy more — Managed services exist for a reason
5. Celebrate incremental wins — “10% better” compounds over time

---

The Takeaway

Eleven years at MercadoLibre taught me that data engineering at scale isn’t about technology — it’s about people, process, and pragmatism.

The best data systems I’ve built were:

• Simple (one source of truth > ten comprehensive tables)
• Visible (dashboards that show what’s happening > clever models)
• Collaborative (cross-functional alignment > solo genius)
• Maintainable (the team can run it without me)

And most importantly: Start where you are. The path doesn’t have to be linear.

---

This post reflects my personal experiences and opinions, not those of MercadoLibre or any employer.