Arquitectura Data Mesh — Propiedad de Datos Descentralizada

Visión General

Data Mesh, introducido por Zhamak Dehghani, es un enfoque socio-técnico para la arquitectura de datos. En lugar de que un equipo central de datos sea dueño de todos los pipelines (el patrón del data lake monolítico), Data Mesh entrega la propiedad a los equipos de dominio que producen el dato, y les pide tratarlo como un producto. Un equipo de plataforma provee infraestructura self-serve para que los dominios puedan publicar, descubrir y consumir datos sin esperar en el backlog central.

El cambio parece pequeño pero transforma quién responde por la calidad. En un lake, se culpa al equipo central por datos rotos o desactualizados que él no produjo. En un mesh, el equipo que mejor conoce el dato lo posee de punta a punta — esquema, frescura, documentación y los consumidores que dependen de él.

Cuándo Usarlo

Adopta Data Mesh cuando el cuello de botella es organizacional, no técnico:

• Tu equipo central de datos tiene un backlog medido en semanas o meses
• Los equipos de dominio entienden sus datos mejor que cualquier equipo central
• Necesitas escalar el trabajo de datos entre muchos equipos sin escalar linealmente un equipo central
• La calidad del dato y el “¿quién es dueño de este dataset?” son discusiones recurrentes
• La organización ya tiene dominios maduros — microservicios, contextos DDD o al menos unidades de negocio claramente separadas
• Los analistas esperan a que alguien más exponga o arregle el dato que necesitan

Si solo necesitas procesamiento de streams y no quieres reorganizar la propiedad del dato, ese es un problema más acotado; mejor consulta la guía de stream processing con Kafka.

Cuándo Evitarlo

Data Mesh se adopta mal con más frecuencia de la que se adopta bien. Sáltalo cuando:

• Tienes menos de ~5 equipos de dominio o ~50 ingenieros: el coste de coordinación supera el beneficio; un lake bien gobernado con un solo equipo es más simple
• El problema real es volumen de datos o rendimiento de queries, no el throughput de equipos; lakes y warehouses resuelven eso sin problema
• No hay capacidad para un equipo de plataforma, ya que alguien tiene que construir y operar la capa self-serve antes de que los dominios puedan usarla
• La dirección lo quiere como buzzword. Mesh es 70% cambio organizacional; sin mandato ejecutivo y un horizonte de 1-2 años, se estanca
• Tus “dominios” son artificiales. Si los equipos no tienen propiedad clara de negocio, solo vas a distribuir el caos

Los Cuatro Principios

Principio	Significado	Implementación práctica
Propiedad orientada al dominio	El equipo que produce el dato es su dueño	Cada equipo de microservicios es dueño de sus data products
Dato como producto	Los consumidores son clientes; importa la calidad y la usabilidad	Esquemas documentados, SLAs y queries de ejemplo
Plataforma de datos self-serve	Infraestructura automatizada y accesible	Pipelines gestionados, catálogos de descubrimiento, herramientas de gobernanza
Gobernanza federada computacional	Estándares globales, implementación local	Políticas centrales de privacidad, cumplimiento local en cada dominio

Propiedad orientada al dominio

El equipo que opera el servicio de Pedidos es dueño de orders.fact_order_events — su esquema, sus SLAs, su documentación. Sabe qué significa “cancelado” en su contexto de negocio; un equipo central a tres saltos de distancia no. La propiedad incluye las partes aburridas: versionar esquemas, responder preguntas de los consumidores y estar de guardia cuando el pipeline se rompe a las 3 AM.

Es el principio más difícil culturalmente. Le estás pidiendo a ingenieros de producto que se preocupen por consumidores analíticos que nunca conocieron. Solo funciona cuando la propiedad es explícita — dueños con nombre en el catálogo, guardias y respaldo ejecutivo.

Dato como producto

Un dataset no es un producto hasta que alguien puede usarlo sin hablar contigo. Eso significa un esquema publicado, una entrada descubrible en el catálogo, SLAs de frescura y completitud, queries de ejemplo y una política clara de deprecación. Si un consumidor tiene que escribirte por Slack para preguntar qué significa la columna X, el producto falló.

Tratar a los consumidores como clientes también implica versionado. Los cambios incompatibles van a una nueva versión mayor, y las versiones viejas siguen vivas lo suficiente para que los consumidores migren — la misma disciplina que una API pública.

Plataforma de datos self-serve

El trabajo del equipo de plataforma es convertir la publicación de un data product en cuestión de configuración, no en un proyecto. Los equipos de dominio no deberían aprovisionar topics de Kafka, administrar clusters de Spark ni escribir DAGs de Airflow a mano. Declaran un esquema, apuntan un pipeline a una fuente, y la plataforma se encarga de storage, lineage, control de acceso y monitoreo.

Sin esta capa, cada dominio reinventa la rueda y el mesh colapsa de vuelta a la inconsistencia. También es donde va la mayor parte del presupuesto — la inversión en plataforma viene antes que el conteo de productos.

Gobernanza federada computacional

La gobernanza en un mesh no es “sin gobernanza”, es federada. Un grupo central define políticas globales (manejo de PII, retención, nombres, formatos de interoperabilidad como Avro o Parquet), y cada dominio las implementa localmente. La parte “computacional” significa que las políticas las aplica la plataforma automáticamente (enmascarar columnas PII, validar compatibilidad de esquemas, registrar lineage) en lugar de comités de revisión.

Arquitectura

La forma es simple: una plataforma compartida debajo, equipos de dominio publicando productos encima, consumidores uniendo productos downstream.

Cada flecha cruza un contrato. Los dominios publican en la capa de ingesta de la plataforma con un esquema registrado. La plataforma persiste los productos en storage compartido, registra el lineage y los expone vía el catálogo. Los consumidores descubren productos ahí y los unen en su propio entorno de cómputo, sin equipo central de por medio.

Especificación de un Data Product

Un data product debe incluir, como mínimo, una spec legible por máquina que el catálogo pueda ingerir:

# data-product.yaml — metadatos para el catálogo
name: orders.fact_order_events
owner: orders-team@company.com
description: Stream de eventos del ciclo de vida del pedido (placed, paid, shipped, delivered)
schema:
  - name: order_id
    type: UUID
    description: Identificador único del pedido
  - name: event_type
    type: STRING
    description: Tipo de evento del pedido
  - name: occurred_at
    type: TIMESTAMP
    description: Marca de tiempo del evento
quality:
  freshness_sla: "5 minutos"
  completeness: "99.9%"
  schema_evolution: backward_compatible
access:
  classification: internal
  pii_fields: [customer_email, customer_address]
examples:
  - "SELECT * FROM orders.fact_order_events WHERE event_type = 'placed'"

Los campos que más importan en la práctica son owner (un equipo real, no una lista de correo que nadie lee), pii_fields (que dispara el enmascarado automático) y los SLAs. Los consumidores filtran el catálogo por frescura primero. Un producto sin SLA es un producto en el que nadie confía.

Implementación

Dos lados del contrato: el dominio publica, el consumidor une. Ambos usan infraestructura real y aburrida; el mesh trata de quién es dueño de qué, no de herramientas exóticas.

# Publicador — Pedidos emite a Kafka (Avro + Schema Registry)
from confluent_kafka.avro import AvroProducer, load

value_schema = load("schemas/order_event.avsc")
producer = AvroProducer(
    {
        "bootstrap.servers": "kafka:9092",
        "schema.registry.url": "https://schema-registry.company.com",
    },
    default_value_schema=value_schema,
)

def on_order_placed(order):
    producer.produce(
        topic="orders.fact_order_events",
        value={
            "order_id": str(order.id),
            "event_type": "placed",
            "customer_id": str(order.customer_id),
            "total": float(order.total),
            "occurred_at": order.created_at.isoformat(),
        },
    )
    producer.flush()

El schema registry valida compatibilidad al publicar, así que un cambio incompatible es rechazado antes de llegar a los consumidores. Eso es gobernanza computacional, no una checklist.

# Consumidor — Analytics une dominios con PySpark en Delta Lake
from pyspark.sql import SparkSession, functions as F

spark = SparkSession.builder.appName("revenue-report").getOrCreate()

orders = spark.read.format("delta").load("s3://mesh/orders/fact_order_events")
payments = spark.read.format("delta").load("s3://mesh/payments/fact_payment_events")

revenue_report = (
    orders.join(payments, on="order_id", how="inner")
    .groupBy(F.window("occurred_at", "1 day"))
    .agg(F.sum("total").alias("revenue"))
)

Fíjate que el consumidor hace el join él mismo. La plataforma provee acceso al storage y el catálogo; unir entre dominios es un problema de cómputo del consumidor, no un ticket al equipo central.

Contratos de Datos y Evolución de Esquemas

El acuerdo entre un dominio y sus consumidores es el contrato de datos: el esquema publicado más los SLAs de la spec. El Schema Registry lo convierte en un contrato exigible, no en una promesa de README:

• Cambios compatibles hacia atrás (agregar un campo opcional) están permitidos y los consumidores siguen funcionando
• Cambios incompatibles (renombrar o eliminar un campo) son rechazados al publicar, así que el dominio tiene que versionar el producto, p.ej. orders.fact_order_events.v2
• La deprecación tiene política: cuando sale v2, v1 sigue viva durante una ventana publicada (típicamente 60-90 días) mientras los consumidores migran

La disciplina de versionado es lo que separa un mesh de un pantano. Sin ella, los dominios se rompen entre sí silenciosamente y los consumidores dejan de confiar en el catálogo, que es justo el fallo que el mesh venía a corregir.

Data Mesh vs Lake vs Lakehouse

No son competidores; responden preguntas distintas:

Enfoque	Responde	Propiedad	Mejor para
Data Lake	¿Dónde vive el dato?	Equipo central	Storage crudo, cargas de ML
Lakehouse	¿Cómo logramos ACID + BI sobre el lake?	Equipo central	Plataforma analítica unificada
Data Mesh	¿Quién responde por el dato?	Equipos de dominio	Escala organizacional

Un mesh normalmente corre sobre un sustrato lakehouse: tablas Delta Lake publicadas por dominios en lugar de un equipo central. Si todavía estás eligiendo la capa de almacenamiento, decide primero el sustrato (lake vs lakehouse), y después evalúa si la propiedad tipo mesh tiene sentido encima.

Componentes de la Plataforma Self-Serve

Componente	Propósito	Herramientas de ejemplo
Catálogo de datos	Descubrir y entender data products	DataHub, Collibra, Amundsen
Schema Registry	Validar y evolucionar esquemas	Confluent Schema Registry, AWS Glue
Control de acceso	Gestionar permisos entre dominios	Apache Ranger, AWS Lake Formation
Seguimiento de lineage	Rastrear el flujo del dato de fuente a consumidor	OpenLineage, Marquez
Monitoreo de calidad	Alertar sobre violaciones de SLA	Great Expectations, Soda Core

No necesitas los cinco desde el día uno. Empieza con catálogo + schema registry, pues son lo que hace a los productos descubribles y confiables. Suma control de acceso cuando llegue el primer producto con PII, y lineage cuando el seguimiento de lineage pase de ser un requisito de compliance a una necesidad de debugging.

Gobernanza Federada en la Práctica

El modelo de gobernanza tiene tres niveles:

• Políticas globales — definidas una vez por un consejo de gobernanza de datos: niveles de clasificación PII, reglas de retención, convenciones de nombres, campos de metadatos obligatorios, formatos aprobados (Avro, Parquet).
• Cumplimiento en la plataforma — automatizado en la capa de plataforma: esquemas validados al publicar, columnas PII enmascaradas según clasificación, lineage registrado automáticamente, acceso concedido por tags de política en lugar de tickets por tabla.
• Responsabilidad del dominio — cada dominio se adhiere a las políticas globales y las implementa: el equipo de Pedidos enmascara customer_email, mantiene fact_order_events dentro de su ventana de retención y documenta los cambios incompatibles.

El modo de fallo es dejar que “federada” derive de vuelta a “centralizada”. Si cada cambio de esquema necesita aprobación del consejo, reconstruiste el cuello de botella con pasos extra. El consejo fija política unas pocas veces al año; la plataforma la aplica todos los días.

Costes y Trade-offs

Cuentas honestas antes de empezar:

• El coste de plataforma se paga por adelantado. El catálogo, el registry, el storage y la capa de acceso existen antes de que salga el primer producto, así que presupuesta varios meses de trabajo de plataforma antes de que ningún dominio vea beneficio.
• La duplicación es el impuesto que pagas por autonomía. Dos dominios pueden modelar “cliente” de forma distinta; los estándares de interoperabilidad (IDs compartidos, formatos canónicos) lo reducen pero no lo eliminan. Acepta duplicación acotada donde los dominios de verdad ven el mundo diferente.
• Los equipos de dominio ganan trabajo que no pidieron. El versionado de esquemas, el monitoreo de SLAs y el soporte a consumidores caen sobre ingenieros que antes solo escribían eventos a un topic. Planifícalo en la capacidad del equipo, no solo en entusiasmo.
• El equipo central no desaparece — se encoge y se reespecializa como equipo de plataforma. El headcount total suele quedarse igual; lo que cambia es la forma del trabajo.

Si esos costes te parecen aceptables, la ruta de migración de abajo es como la mayoría de organizaciones llega.

Ruta de Migración

No migres el lake; haz crecer el mesh a su alrededor:

1. Elige 2-3 dominios piloto con equipos dispuestos y datos de alto valor (los dominios de métricas y reportes que todos ya consultan).
2. Monta las piezas mínimas de plataforma: catálogo + schema registry. Salta todo lo demás hasta que los pilotos demuestren demanda.
3. Publica los productos piloto con specs completas: esquema, dueño, SLAs, campos PII. Ellos marcan el estándar de calidad para los que vengan.
4. Mide el antes y el después: tiempo-para-dato de los consumidores, solicitudes acumuladas en el backlog central, cumplimiento de SLAs. Publica esos números internamente.
5. Expande por atracción, no por imposición: cuando otros equipos ven consumidores obteniendo datos en un día en lugar de seis semanas, se ofrecen solos. La adopción forzada produce productos que nadie usa.

El escenario completo de abajo recorre un piloto realista de 4 meses.

Escenario Detallado: Data Mesh en E-commerce

Organización: E-commerce con 8 equipos de dominio
Problema: Equipo central de datos con backlog de 6 meses
Objetivo: 3 data products piloto en 4 meses

Fase 1: Identificar dominios y productos piloto (mes 1)
  Dominios identificados:
    - Pedidos (equipo A): dueño de eventos del ciclo del pedido
    - Pagos (equipo B): dueño de eventos de pago y reembolso
    - Inventario (equipo C): dueño de niveles y movimientos de stock

  Productos piloto seleccionados:
    1. orders.fact_order_events (stream de eventos)
    2. payments.fact_payment_events (stream de eventos)
    3. inventory.current_stock_levels (tabla snapshot)

  Criterios de selección:
    - Alto valor de negocio (los consumen analytics y ML)
    - Equipo de dominio dispuesto a publicar
    - Esquema estable (no en refactor activo)

Fase 2: Construir la plataforma mínima (mes 2)
  Componentes implementados:
    - Catálogo: DataHub (open source) para descubrimiento
    - Schema Registry: Confluent Schema Registry para Avro
    - Storage: S3 con Delta Lake para ACID
    - Acceso: AWS Lake Formation para permisos entre dominios
    - Lineage: OpenLineage + Marquez para trazabilidad

  $ docker-compose up datahub-backend datahub-frontend schema-registry
  $ aws lakeformation grant-permissions \
      --principal DataLakePrincipalIdentifier=orders-team \
      --permissions SELECT \
      --resource TableWithColumns=orders.fact_order_events

Fase 3: Publicar los productos piloto (mes 3)
  El equipo de Pedidos publica fact_order_events:
    - Definir esquema Avro en el Schema Registry
    - Configurar pipeline: Kafka -> S3 Delta Lake
    - Registrar metadatos en DataHub con SLAs
    - Configurar alertas de calidad (Great Expectations)

  Especificación publicada:
    name: orders.fact_order_events
    owner: orders-team@company.com
    freshness_sla: 5 minutos
    completeness: 99.9%
    pii_fields: [customer_email]

Fase 4: Consumo entre dominios (mes 4)
  El equipo de Analytics se suscribe a los 3 productos:
    orders = consumer.subscribe("orders.fact_order_events")
    payments = consumer.subscribe("payments.fact_payment_events")
    inventory = consumer.subscribe("inventory.current_stock_levels")

  Reporte de ingresos creado con join entre dominios:
    SELECT o.order_id, o.total, p.paid_amount, i.stock_level
    FROM orders.fact_order_events o
    JOIN payments.fact_payment_events p ON o.order_id = p.order_id
    JOIN inventory.current_stock_levels i ON o.product_id = i.product_id

Métricas de éxito (a los 6 meses):
  | Métrica | Antes | Después |
  |---------|-------|---------|
  | Tiempo de acceso al dato | 6 semanas (solicitud al equipo central) | 1 día (self-service) |
  | Data products | 0 | 12 |
  | Equipos publicando | 1 (central) | 5 |
  | Calidad del dato (SLA cumplido) | N/A | 97.3% |

La métrica que más importa es el tiempo de acceso al dato: de 6 semanas a 1 día es todo el argumento. El conteo de productos y el cumplimiento de SLAs son evidencia de apoyo, no el objetivo.

Errores Comunes

• Declarar Data Mesh sin dominios claros — necesitas dominios bien delimitados primero; si no, solo distribuyes el caos
• Ignorar la gobernanza — gobernanza federada no es “sin gobernanza”; define estándares globales de privacidad, seguridad e interoperabilidad
• Esperar ROI inmediato — los cambios culturales y organizacionales toman tiempo; planifica un viaje de 1-2 años
• Tratarlo como puramente técnico — Data Mesh es 70% cambio organizacional, 30% tecnología
• Construir la plataforma antes que los productos — empieza con 2-3 data products piloto, luego construye la plataforma alrededor de necesidades reales
• Publicar productos que nadie consume — un data product con cero consumidores es inventario, no un activo. Mide adopción antes de escalar el conteo
• Volver a centralizar la gobernanza — si cada cambio de esquema necesita un comité, el mesh se vuelve un lake más lento

Ver También

• Dehghani — Principios de Data Mesh (martinfowler.com) — la definición original de los cuatro principios.
• Documentación de DataHub — el catálogo open source usado en el escenario.
• Confluent Schema Registry — validación de esquemas Avro.
• OpenLineage — el estándar de lineage detrás de Marquez.
• AWS Lake Formation — control de acceso a nivel de columna.
• Ejemplos companion — la spec de data product y el esquema Avro de esta guía.