--- bc_id: BCI-MercadoLibre-Fury-v01 bc_type: INICIATIVA source_name: MercadoLibre — Fury (Internal Developer Platform) type: BCI version: v01 status: Draft — reconstrucción 2026-07-18 owner: Victor Heredia sherpa_owner: SherpaX (Room Taller Directivo Posta · IBX) ratificador: Victor Heredia intellbank: IB-EL-EmpowerLabs subbank: BC-EL-BrainCodes proposito: Brain Code de iniciativa — Fury, la plataforma interna de desarrollo de MercadoLibre. Caso de referencia del IBX: cómo se escala inteligencia organizacional con una capa de plataforma en vez de con más coordinación humana. reconstruye: BC-MercadoLibre-FURY-v01 (huérfano — entrada en Registry sin archivo en disco) distillation_date: 2026-07-18 distiller_version: MasterDistiller-v02 materials_used: - tipo: ingenieria referencia: Mercado Libre Tech (Medium) — Kubernetes at Mercado Libre · evolución monolito→multicloud · observabilidad - tipo: conferencia referencia: QCon SF 2024 — Scaling Innovation with NoOps · PlatformEngineering.org - tipo: filings referencia: MELI 10-Q FY2025 · FY2026 (SEC EDGAR) — capex logístico y tecnológico confidence: logros: media-alta proceso_transformacion: alta reglas_decision: media anti_patrones: media-alta tensiones: media readiness_score: ⭐⭐⭐⭐ (4/5 — MELI publica su ingeniería con inusual detalle) coverage_note: | Fuerte en arquitectura, escala y filosofía de plataforma (material público abundante y técnico). Débil en gobierno interno de decisiones de producto y en la conexión fina entre Fury y la operación logística física. usage_modes: [AUDITORÍA, BOARD, IBX-BENCHMARK, CASO-REFERENCIA] tags: [BCI, BrainCode, MercadoLibre, Fury, plataforma, IBX, NoOps, inteligencia-organizacional] --- # BCI — MercadoLibre · Fury (Internal Developer Platform) > **Por qué este BCI importa para el IBX.** Fury es el caso más limpio del principio central del playbook de gobernanza: **cuando la complejidad crece, se responde con estructura inteligente, no con más coordinación humana.** MELI pasó de ~2,000 a ~12,000+ ingenieros sin multiplicar proporcionalmente la carga de coordinación — porque puso una capa de plataforma entre la gente y la complejidad. --- ## O1 — Objeto de la iniciativa **Qué es:** una **plataforma interna de desarrollo (IDP)** —web + CLI + SDKs/APIs— que se sitúa entre los desarrolladores y los proveedores de nube, y les permite crear, desplegar, monitorear y operar servicios sin gestionar servidores. - **Usuarios directos:** la organización de ingeniería de MELI (~16,000 desarrolladores soportados). - **Escala operativa:** más de **30,000 microservicios**; ~**50 millones de requests por segundo**; ~**10,000 despliegues por día**. - **Arquitectura:** modelo interno llamado *Serverless* — abstracción total del servidor; Kubernetes gestionado (EKS/GKE) por debajo; cloud-agnóstico. - **Geografía:** toda la operación de MELI en Latinoamérica (y su expansión a EE.UU.). ## O2 — Objetivo Que la **velocidad de entrega por ingeniero no se degrade cuando la organización se multiplica** — eliminando de la carga cognitiva del desarrollador todo lo que no es su dominio de negocio. ## C1 — Configuración - **Stack:** Kubernetes gestionado (EKS, GKE) como sustrato; capa de abstracción propia (*Fury*) que oculta el sustrato; Go como lenguaje de alto peso en el stack; observabilidad integrada (trazas distribuidas y profiling como señales de telemetría de primera clase). - **Modelo de gobierno:** equipo de plataforma con "back office" propio para operar la plataforma; los equipos de producto consumen la plataforma, no la infraestructura. - **Filosofía operativa:** **NoOps** — no que no haya operaciones, sino que la operación esté absorbida por la plataforma y no por cada equipo. ## L1 — Logros | Métrica | Valor | Confianza | |---|---|---| | Microservicios gestionados | **+30,000** | [D] pública, consistente en múltiples fuentes | | Desarrolladores soportados | **~16,000** | [D] | | Requests por segundo | **~50 M/s** | [D] | | Despliegues por día | **~10,000** | [D] | | Escalamiento de la organización | **~2,000 → ~12,000+ ingenieros** manteniendo el ritmo de entrega | [D] charla pública | | Capex tecnológico (Q1 2026) | **$105 M** en activos de información y tecnología (BR/MX/AR) | ✓ 10-Q FY2026 | | Capex logístico (Q1 2026) | **$146 M** en instalaciones de envío y otros | ✓ 10-Q FY2026 | | Red logística | **+30 centros de fulfillment**, ~**57%** de los envíos de la región gestionados | [D] | ✓ = verificado en filing · [D] = declaración pública de la compañía o de sus ingenieros ## V1 — Valor generado - **Moat organizacional:** la ventaja no es un algoritmo — es que **incorporar 1,000 ingenieros nuevos no multiplica el costo de coordinación**. Eso es difícil de copiar y no se compra. - **Velocidad como propiedad estructural:** 10,000 despliegues diarios no se logran con disciplina; se logran con una plataforma que hace barato el despliegue seguro. - **Opcionalidad cloud:** ser cloud-agnóstico convierte a los proveedores en commodity intercambiable. - **Capacidad nueva:** experimentar es barato → la organización puede aprender más rápido que sus competidores. --- ## MM — Modelos Mentales (7) 1. **Platform Thinking** — se construye para la plataforma, no para el caso puntual. *Explica:* por qué invierten en abstracción en vez de resolver cada necesidad ad hoc. 2. **Carga cognitiva como recurso escaso** — la atención del ingeniero es el cuello de botella real, no el cómputo. *Explica:* la obsesión con abstraer el servidor. 3. **Ley de Conway** — la arquitectura del sistema refleja la arquitectura de comunicación. *Explica:* 30,000 microservicios ≈ equipos autónomos con contratos claros. 4. **Ley de Variedad Requerida (Ashby/Beer)** — para absorber más complejidad se necesita más inteligencia estructural, no más esfuerzo. *Explica:* la tesis completa de Fury. **Es el puente directo con el playbook de gobernanza.** 5. **Abstracción como gobernanza** — la plataforma no *sugiere* buenas prácticas: las hace el camino por defecto. *Explica:* por qué no dependen de documentación ni de disciplina individual. 6. **Flywheel de plataforma** — más equipos usando la plataforma → más señales → mejor plataforma → más adopción. 7. **Commoditización del proveedor** — el cloud-agnosticismo convierte una dependencia estratégica en una decisión reversible. ## SC — Stack de Ciencias Aplicadas - **Sistemas Distribuidos** → orquestación de contenedores, service discovery, tolerancia a fallos. *Fundamento:* teoría de sistemas distribuidos (consenso, particionamiento). *Aplicación:* sustrato Kubernetes gestionado. - **Ingeniería de Observabilidad** → trazas distribuidas + profiling continuo como señales de telemetría. *Fundamento:* Dapper (Google, 2010) y linaje OpenTelemetry. *Aplicación:* un ecosistema de observabilidad a escala que hace diagnosticable un sistema de 30k servicios. - **Teoría de Colas / Capacity Planning** → dimensionamiento para ~50M RPS. - **Cibernética Organizacional (VSM)** → *(lectura interpretativa)* la plataforma opera como el sistema de coordinación que permite autonomía local sin pérdida de cohesión global. ## PT — Proceso de Transformación ``` ESTADO A (ANTES) Descripción: monolito; cada equipo lidiando con infraestructura; el costo de coordinación creciendo más rápido que el equipo. Fallas: la velocidad por ingeniero se degradaba al crecer la organización; ineficiencias operativas repetidas equipo por equipo. Costo del status quo: el techo de escalamiento — sumar gente dejaba de sumar producto. MECANISMO DE TRANSFORMACIÓN Fase 1 · Descomposición — del monolito a microservicios con ownership claro por dominio. Fase 2 · Abstracción (Fury) — construir la capa que oculta la infraestructura: UI + CLI + SDKs; el desarrollador deja de ver servidores. Fase 3 · Kubernetes gestionado — migrar el sustrato a EKS/GKE, resolviendo ineficiencias operativas sin romper la abstracción que los equipos ya usaban. Fase 4 · Observabilidad de primera clase — trazas y profiling dentro de Fury, para que un sistema de 30k servicios siga siendo diagnosticable. Palancas clave: (1) la abstracción se hizo el camino por defecto, no una opción (2) el sustrato se pudo cambiar sin cambiar la experiencia del desarrollador (3) la plataforma se trató como producto interno, con equipo dedicado ESTADO B (DESPUÉS) Descripción: +30,000 microservicios, ~16,000 desarrolladores, ~10,000 despliegues/día, ~50M RPS, cloud-agnóstico. Capacidades nuevas: escalar la organización sin escalar proporcionalmente la coordinación; cambiar de proveedor de nube sin reescribir; experimentar barato. ``` ## RD — Reglas de Decisión 1. **Si** una necesidad de infraestructura aparece en más de un equipo → **entonces** absorberla en la plataforma, no resolverla por equipo. *Origen:* la lógica misma del IDP. *Contexto:* aplica cuando el patrón se repite; **NO aplica** a necesidades genuinamente singulares. 2. **Si** el desarrollador necesita conocer el servidor para hacer su trabajo → **entonces** la abstracción está incompleta. *Es el test de calidad de la plataforma.* 3. **Si** cambia el sustrato (proveedor, orquestador) → **entonces** la experiencia del desarrollador no debe cambiar. *Evidencia:* la migración a Kubernetes gestionado sin romper la adopción existente. 4. **Si** un sistema no es observable → **entonces** no es operable a esta escala. *Origen:* la decisión de elevar trazas y profiling a señales de primera clase. 5. **Si** la buena práctica depende de que la gente la recuerde → **entonces** no es una práctica, es un deseo. Hacerla el default. ## AP — Anti-Patrones - **No exponen la infraestructura a los equipos de producto.** *Por qué parece obvio:* dar control total parece empoderar. *Por qué lo evitan:* multiplica la carga cognitiva por el número de equipos y produce 12,000 formas distintas de hacer lo mismo. *Costo:* la coordinación crece cuadráticamente. - **No resuelven con documentación lo que se puede resolver con abstracción.** *Por qué lo evitan:* la documentación depende de la disciplina individual; la plataforma no. - **No se casan con un proveedor de nube.** *Por qué parece obvio:* la integración profunda con un proveedor da eficiencia. *Por qué lo evitan:* convierte una decisión reversible en una dependencia estratégica. - **No tratan la plataforma como proyecto de infraestructura.** *La tratan como producto interno con usuarios, adopción y equipo dedicado.* Un proyecto termina; un producto evoluciona. - **No centralizan las decisiones de producto para lograr coherencia.** *Logran coherencia por la vía del default de plataforma, no por la vía del comité.* **Este anti-patrón es el más relevante para Posta.** ## TF — Tensiones Fundamentales - **Autonomía ↔ Estandarización.** Equipos autónomos entregan rápido; estándares comunes hacen el sistema gobernable. *Cómo la gestionan:* la plataforma impone el estándar por la vía del camino más fácil, no de la prohibición. *Señal de desequilibrio:* equipos construyendo alrededor de Fury en vez de sobre Fury. - **Abstracción ↔ Control.** Ocultar el servidor libera al desarrollador y le quita palancas cuando algo falla raro. *Cómo la gestionan:* observabilidad profunda como compensación de la abstracción. - **Velocidad ↔ Estabilidad.** 10,000 despliegues/día es velocidad; también es superficie de riesgo. - **Inversión en plataforma ↔ Inversión en producto.** Cada ingeniero en plataforma no está en features. *Es una apuesta de segundo orden* — se paga en velocidad de todos los demás. ## ML-LOOP — Mecanismo de Aprendizaje ``` CICLO DE APRENDIZAJE Unidad: el equipo que consume la plataforma. Señal: fricción de adopción + telemetría de uso + trazas/profiling del comportamiento real de los servicios. Escala temporal: continua (10,000 despliegues/día = feedback constante). Retroalimentación: la fricción repetida entre equipos se convierte en la siguiente capacidad de la plataforma → más adopción → más señal. Propiedad clave: el loop es de plataforma, no de proyecto — no termina. ``` ## FK — Frontier Knowledge - **Platform Engineering como disciplina formal** — MELI es uno de los casos de referencia del campo; el frente actual es la medición del *developer experience* como métrica de negocio. - **Data Mesh** (Dehghani) — ownership distribuido de datos por dominio: el análogo de Fury en la capa de datos. - **Agentes de IA sobre la plataforma** — la frontera abierta: usar la telemetría de una plataforma de esta escala para que agentes diagnostiquen y remedien sin humano en el loop. --- ## Lectura para el IBX y para Posta **Para el IBX — el contraste que define el índice:** | | FedEx (DRIVE) | MercadoLibre (Fury) | |---|---|---| | Naturaleza del activo | Red **física** | Red **digital** sobre red física | | Palanca de inteligencia | Rediseño estructural de red | Capa de plataforma que absorbe complejidad | | Cómo escalan | Consolidando activos | Abstrayendo carga cognitiva | | Horizonte del loop | Plurianual, por lotes | Continuo, diario | | Qué compran con ello | Costo estructural permanente | Velocidad organizacional permanente | Ambos responden la misma pregunta —*¿cómo absorbo más complejidad sin quemar a mi gente?*— con la misma respuesta estructural y distinta implementación. **Ninguno de los dos lo resolvió pidiendo más esfuerzo.** Ese es el hallazgo del IBX. **Para Posta — el paralelo incómodo:** Posta tiene el problema de MELI (complejidad creciente, muchos proyectos, dependencias cruzadas, gente al tope) y está usando la solución que MELI descartó explícitamente: **coordinación humana heroica**. Fury demuestra que a partir de cierta complejidad, la coordinación manual deja de escalar — no por falta de talento, sino por matemática. La regla #5 de Fury es literalmente el argumento del taller: > *Si la buena práctica depende de que la gente la recuerde, no es una práctica — es un deseo. Hazla el default.* Eso es gobernanza instrumentada, no gestión del caos. --- ## CAL — Calibración - La mayoría de las cifras de escala son **declaraciones públicas de la compañía y sus ingenieros** [D], no auditadas. Las de capex sí provienen de filings ✓. Distinguirlas al citar. - Este BCI modela una **plataforma de software**. Sus reglas se transfieren a Posta como *analogía estructural*, no como receta técnica — Posta no necesita construir un Fury; necesita el principio (absorber complejidad con estructura, no con esfuerzo). - No extrapolar de este BCI conclusiones sobre prácticas laborales, cultura interna o decisiones de negocio de MELI: no hay material destilado sobre eso. --- *BCI-MercadoLibre-Fury-v01 · Reconstruido 2026-07-18 · Room Taller Directivo Posta · Owner+Ratificador: Victor Heredia* **Fuentes:** [Kubernetes at Mercado Libre (MELI Tech)](https://medium.com/mercadolibre-tech/kubernetes-at-mercado-libre-ec331bea1866) · [La evolución tecnológica: del monolito a la plataforma multicloud](https://medium.com/mercadolibre-tech/the-technological-evolution-at-mercado-libre-fb269776a4e8) · [Mercado Libre's Internal Developer Platform (PlatformEngineering.org)](https://platformengineering.org/blog/unveiling-the-secrets-of-a-successful-journey-mercado-libres-internal-developer-platform) · [QCon SF 2024 — Scaling Innovation with NoOps](https://qconsf.com/presentation/nov2024/scaling-innovation-noops-how-mercado-libre-manages-30000-microservices-and-25) · [MELI 10-Q FY2026 (SEC)](https://www.sec.gov/Archives/edgar/data/0001099590/000109959026000017/meli-20260331.htm)