Sembilan chapter sebelumnya memperkenalkan pola demi pola, masing-masing dengan kekuatan dan biayanya sendiri. Masalahnya, tidak ada pola yang menang di semua dimensi — Medallion murah dioperasikan tetapi lambat, Kappa segar tetapi menuntut log terkelola, mesh responsif terhadap organisasi tetapi mahal secara koordinasi. Memilih arsitektur dengan cara “pilih yang paling populer” adalah resep kekecewaan. Bab ini menyusun proses pemilihan yang bisa dipertanggungjawabkan: pohon keputusan untuk menyaring, matriks skor tertimbang untuk membandingkan, dan constraint keras yang berdiri di atas keduanya.

Mulai dari Kebutuhan, Bukan Teknologi #

Setiap keputusan arsitektur dimulai dari pertanyaan kebutuhan, dan jawabannya harus terukur. Lima pertanyaan berikut menutupi sebagian besar keputusan nyata:

  • Berapa kesegaran yang dibutuhkan konsumen — jam, menit, atau detik? (nyatakan sebagai latensi p95, bukan kata “cepat”)
  • Berapa volume data harian dan laju pertumbuhannya?
  • Berapa banyak domain dan tim yang terlibat, dan siapa yang akan memiliki datanya?
  • Batas regulasi apa yang berlaku — retensi, lokasi penyimpanan, audit?
  • Berapa anggaran operasional yang sanggup dipegang untuk dua belas bulan?

Jawaban atas kelima pertanyaan tersebut memetakan kita ke wilayah pohon keputusan berikut:

Pohon keputusan mempersempit kandidat, tetapi jarang menetapkan satu pemenang. Untuk itu kita perlu matriks skor.

Matriks Skor Tertimbang #

Kasusnya TokoKita pada akhir 2026: deteksi penipuan menjadi prioritas dan butuh data segar, sementara tim data tetap kecil dan biaya diawasi ketat. Lima kandidat dinilai pada lima kriteria berskala 1-5, dan setiap kandidat membawa satu angka terukur — latensi p95 hasil pengukuran ala chapter Benchmarking:

python
# Kandidat "cetak biru" awal: (skor per kriteria 1-5, latensi p95 detik)
# urutan kriteria: kesegaran, beban operasional, biaya, kesederhanaan, regulasi
KANDIDAT = {
    "layered sederhana": ((1, 5, 5, 5, 3), 2700),
    "medallion": ((2, 4, 4, 4, 4), 2700),
    "kappa": ((5, 2, 3, 2, 3), 8),
    "lambda": ((4, 1, 2, 1, 3), 15),
    "data mesh": ((2, 1, 2, 1, 5), 900),
}

# Bobot disepakati pemangku kepentingan: fraud butuh data segar, tim tetap kecil
BOBOT = {"kesegaran": 4, "beban operasional": 3, "biaya": 3,
         "kesederhanaan": 3, "regulasi": 2}
URUTAN = list(BOBOT)  # urutan sama dengan tuple skor

CONSTRAINT_DETIK = 10  # deteksi penipuan: latensi p95 di bawah 10 detik


def skor(nilai):
    return sum(n * BOBOT[k] for n, k in zip(nilai, URUTAN))

Tahap penyaringan constraint kemudian mengeliminasi kandidat yang latensinya melewati batas:

python
def tahap_dua():
    print(f"Tahap 2 - constraint keras: latensi p95 di bawah {CONSTRAINT_DETIK} detik")
    lolos, gugur = [], []
    for nama, (_, latensi) in KANDIDAT.items():
        (lolos if latensi <= CONSTRAINT_DETIK else gugur).append((nama, latensi))
    for nama, latensi in sorted(lolos):
        print(f"  lolos   : {nama:<18} p95 {latensi} detik")
    for nama, latensi in sorted(gugur):
        print(f"  gugur   : {nama:<18} p95 {latensi} detik")
    return [n for n, _ in lolos]

Fungsi pencetakan matriks serta tahap_satu dan tahap_tiga (pengurutan skor sederhana) dipangkas dari tampilan; hasil eksekusi skrip lengkap berikut:

Output yang Dihasilkan:

text
=== Matriks skor (skala 1-5) ===
kandidat            kesegaran  beban ope      biaya  kesederha   regulasi  total
data mesh                   2          1          2          1          5     30
kappa                       5          2          3          2          3     47
lambda                      4          1          2          1          3     34
layered sederhana           1          5          5          5          3     55
medallion                   2          4          4          4          4     52

Tahap 1 - skor tanpa constraint:
  1. layered sederhana  55
  2. medallion          52
  3. kappa              47
  4. lambda             34
  5. data mesh          30
Juara tanpa constraint: layered sederhana (55), peringkat 3: kappa (47)

Tahap 2 - constraint keras: latensi p95 di bawah 10 detik
  lolos   : kappa              p95 8 detik
  gugur   : data mesh          p95 900 detik
  gugur   : lambda             p95 15 detik
  gugur   : layered sederhana  p95 2700 detik
  gugur   : medallion          p95 2700 detik

Tahap 3 - skor ulang hanya yang lolos:
  1. kappa              47

Juara tanpa constraint : layered sederhana (55 poin)
Rekomendasi akhir      : KAPPA
Matriks tunduk pada constraint, bukan sebaliknya.

Mari kita telaah baris-baris kode di atas:

  1. Blok pertama, baris 3-9 (KANDIDAT): setiap kandidat memuat tuple lima skor dan satu latensi p95 terukur — penilaian kualitatif dipisahkan dari angka pengukuran agar keduanya tidak saling menyamar.
  2. Blok pertama, baris 12-15 (BOBOT): bobot disepakati bersama pemangku kepentingan sebelum melihat skor; kesegaran diberi bobot tertinggi karena deteksi penipuan adalah prioritas bisnis.
  3. Blok pertama, baris 17 (CONSTRAINT_DETIK): satu kebutuhan yang tidak bisa dinegosiasikan lewat skor — batas 10 detik datang dari kebutuhan sistem deteksi, bukan preferensi tim.
  4. Blok pertama, baris 20-21 (skor): perkalian titik bobot terhadap skor menghasilkan total tertimbang; URUTAN menjaga urutan tuple selaras dengan kamus bobot.
  5. Blok kedua (tahap_dua): latensi di atas batas berarti kandidat tereliminasi langsung — fungsi ini memisahkan kandidat ke daftar lolos dan daftar sisanya sebelum skor dihitung ulang.

Constraint Menundukkan Matriks #

Perhatikan pembalikan pada output: juara tahap pertama adalah layered sederhana dengan 55 poin — paling murah, paling sederhana, paling ringan dioperasikan. Namun p95 2.700 detik jauh melampaui batas 10 detik, sehingga seluruh keunggulan skornya tidak relevan. Hanya Kappa yang lolos, dan rekomendasi akhir pun Kappa. Inilah pelajaran metodologis bab ini: matriks skor mengurutkan pilihan yang sah, sedangkan constraint menentukan pilihan mana yang sah.

Kandidat yang lolos kerap berdiri di atas fondasi spesifik — misalnya Kappa menuntut log berretensi panjang ala Kafka , dan Medallion menuntut table format ala Apache Iceberg — sehingga biaya fondasi ikut diperhitungkan dalam skor.

Matriks menghasilkan satu pemenang, tetapi angka di dalamnya menyembunyikan asumsi: berapa sebenarnya harga sebuah menit kesegaran? Chapter penutup section ini, Trade-off Arsitektur, membedahnya dengan perhitungan nyata.