Data Mesh

Layered, Medallion, Lambda, dan Kappa memusatkan seluruh data pada satu platform yang dikelola satu tim. Pola tersebut bekerja hingga jumlah domain bisnis bertambah: tim data menjadi antrean tunggal, domain menunggu berminggu-minggu agar datanya bisa dipakai, dan konteks bisnis hilang di tangan orang yang tidak memahaminya. Data mesh, dirumuskan Zhamak Dehghani, membalik arah tersebut: domain bisnis memiliki datanya sendiri sebagai produk — data product — dengan kontrak yang jelas seperti produk perangkat lunak. Bab ini membedah empat prinsipnya dan membangun pemeriksa kontrak data product secara otomatis.

Empat Prinsip Data Mesh #

Data mesh bukan sebuah tool, melainkan serangkaian prinsip operasional. Keempatnya saling menopang: kepemilikan menempatkan data pada orang yang paham konteksnya, bentuk produk menuntut kontrak, platform mandiri membuat domain bisa bergerak tanpa antre, dan tata kelola federasi menjaga standar lintas domain.

Prinsip	Pertanyaan kunci	Artifact utama
Domain ownership	siapa yang paling memahami data ini	data product per domain
Data as a product	apakah layak dikonsumsi pihak lain	kartu data product, SLO, schema
Self-serve data platform	bisakah domain membangun tanpa antre	templat pipeline, katalog
Federated computational governance	bagaimana standar dijaga lintas domain	kebijakan, schema registry

flowchart TD AN["Analis dan tim ML konsumsi data product"] subgraph D1["Domain Pesanan"] PA[("data product pesanan_harian")] end subgraph D2["Domain Pengiriman"] PB[("data product status_pengiriman")] end subgraph D3["Domain Pembayaran"] PC[("data product mutasi_pembayaran")] end PA --> AN PB --> AN PC --> AN SSP["Self-serve platform templat pipeline dan katalog"] FG["Federated governance standar schema dan akses"] SSP -.-> PA SSP -.-> PB SSP -.-> PC FG -.-> PA FG -.-> PB FG -.-> PC

Data Product dan Kartu Kontraknya #

Data product adalah unit terkecil mesh: dataset yang dimiliki satu domain, punya pemilik, versi, SLO, dan konsumen terdaftar. Semua informasi tersebut dinyatakan dalam satu kartu berformat YAML — konsep yang bersanak keluarga dengan Data Contracts pada section Data Quality dan Observability. Berikut kartu milik domain Pesanan TokoKita:

yaml
# Kartu data product - pesanan_harian (domain Pesanan, TokoKita)
nama: pesanan_harian
versi: 1.3.0
owner: tim-pesanan
domain: pesanan
deskripsi: >-
  Satu baris per pesanan selesai, sudah didedup dan divalidasi,
  siap dipakai analisis dan pelatihan model.
slo:
  freshness_menit: 30
  coverage_persen: 99.9
  schema_url: https://example.com/schemas/pesanan_harian.v1.3.json
kontak: slack://data-pesanan
konsumen_terdaftar:
  - tim-growth
  - tim-keuangan

Pemeriksa kartu adalah kode kecil yang menolak data product tanpa kontrak lengkap — gerbang kualitas versi organisasi, serumpun dengan gerbang medallion pada chapter Medallion Architecture:

python
"""Pemeriksa kartu data product: field wajib dan batas SLO."""
from pathlib import Path

import yaml

KARTU = Path(__file__).parent / "slo_card.yaml"
WAJIB = ["nama", "versi", "owner", "domain", "slo", "kontak", "konsumen_terdaftar"]
BATAS = {"freshness_menit": 60, "coverage_persen": 99.0}


def periksa(kartu):
    masalah = []
    for kolom in WAJIB:
        if kolom not in kartu:
            masalah.append(f"kolom wajib hilang: {kolom}")
    slo = kartu.get("slo")
    if isinstance(slo, dict):
        if slo.get("freshness_menit", 10**9) > BATAS["freshness_menit"]:
            masalah.append(f"freshness {slo['freshness_menit']} menit di atas batas "
                           f"{BATAS['freshness_menit']} menit")
        if slo.get("coverage_persen", 0) < BATAS["coverage_persen"]:
            masalah.append(f"coverage {slo['coverage_persen']}% di bawah batas "
                           f"{BATAS['coverage_persen']}%")
    if not kartu.get("konsumen_terdaftar"):
        masalah.append("tidak ada konsumen terdaftar")
    return masalah

Pemanggilan pemeriksa untuk kartu pesanan_harian dan untuk kartu rusakan (stok_gudang tanpa SLO) dipangkas dari tampilan; hasil eksekusi keduanya berikut:

Output yang Dihasilkan:

text
=== Kartu data product: pesanan_harian v1.3.0 ===
owner   : tim-pesanan (domain pesanan)
slo     : freshness <= 30 menit, coverage >= 99.9%
kontak  : slack://data-pesanan
konsumen: tim-growth, tim-keuangan
status  : LULUS

Kartu 'stok_gudang' tanpa SLO dan konsumen:
status  : DITOLAK
  - kolom wajib hilang: versi
  - kolom wajib hilang: domain
  - kolom wajib hilang: slo
  - kolom wajib hilang: kontak
  - kolom wajib hilang: konsumen_terdaftar
  - tidak ada konsumen terdaftar

Mari kita telaah baris-baris kode di atas:

Baris 7 (WAJIB): tujuh field wajib kartu; kartu tanpa salah satunya langsung ditolak, terlihat pada enam masalah yang dilaporkan untuk stok_gudang.
Baris 18-20 (batas freshness): nilai bawaan 10**9 memastikan SLO yang tidak menyebut freshness_menit dilaporkan sebagai masalah, bukan dianggap lolos begitu saja.
Baris 21-23 (batas coverage): cakupan minimum 99,0% memberi tahu konsumen seberapa lengkap data yang dijanjikan pemiliknya.
Baris 24-25 (konsumen terdaftar): data product tanpa konsumen terdaftar adalah indikasi kartu diisi demi formalitas; mesh menuntut bukti pemakai nyata.

Kapan Mesh Masuk Akal #

Mesh menuntut kematangan organisasi: domain harus punya kapasitas engineering, tata kelola federasi harus benar-benar berjalan, dan platform mandiri harus tersedia. Untuk organisasi kecil dengan satu tim data dan sedikit domain, arsitektur terpusat seperti Medallion justru lebih murah dan lebih cepat.

Rumusan resmi keempat prinsip data mesh ditulis Zhamak Dehghani di martinfowler.com .

Mesh mendesentralisasi kepemilikan, tetapi tidak semua organisasi sanggup atau perlu berjalan ke arah sana. Pendekatan lawannya menarik perhatian industri beberapa tahun kemudian: menyatukan kembali silo-silo tersebut lewat metadata aktif. Chapter Data Fabric membedahnya.