Belajar Solution Architect - Architecture Selection & Trade-offs
Belajar memilih gaya arsitektur secara objektif: membandingkan monolith, modular monolith, microservices, serverless, dan event-driven, menyusun weighted scoring matrix untuk menilai opsi terhadap requirement kalian, serta membekukan keputusan dalam ADR
#Pendahuluan
Setelah di episode 3 kalian bisa mengekstrak requirement yang terukur dan memetakannya lewat traceability matrix, pertanyaan berikutnya muncul: arsitektur seperti apa yang paling cocok dengan requirement itu? Inilah keputusan paling mahal yang diambil seorang SA — karena gaya arsitektur menentukan biaya operasional, kecepatan tim, dan batas scaling selama bertahun-tahun.
Mengapa ini sulit? Karena tidak ada arsitektur terbaik secara mutlak — hanya ada yang paling pas untuk konteks tertentu. Microservices yang menyelamatkan Netflix bisa menghancurkan startup 6 orang. Tugas kalian bukan mengikuti tren, melainkan menjalankan trade-off analysis yang jujur dan terdokumentasi.
#Kandidat Utama Gaya Arsitektur
Lima gaya yang paling sering dipertimbangkan:
| Gaya | Karakter | Paling Cocok Untuk | Risiko Utama |
|---|---|---|---|
| Monolith | Satu deployable unit | Tim kecil, produk baru, MVP | Lambat scaling organisasi saat besar |
| Modular monolith | Monolith dengan boundary modul ketat | Tim sedang, domain jelas | Disiplin boundary harus dijaga |
| Microservices | Service kecil per domain, deploy independen | Tim banyak, skala besar | Kompleksitas ops & distributed debugging |
| Serverless / FaaS | Function per event, zero server management | Traffic spike, workload sporadis | Cold start, vendor lock-in, debugging |
| Event-driven | Komponen berkomunikasi via event/queue | Integrasi banyak sistem, async workflow | Konsistensi akhir, sulit trace alur |
Dua catatan penting tentang mitos yang beredar:
- "Microservices lebih scalable" — setengah benar. Scalability monolith bisa dicapai dengan replika + load balancer; yang benar-benar dibeli dari microservices adalah scalability organisasi (banyak tim deploy tanpa saling menunggu).
- "Serverless selalu lebih murah" — hanya untuk traffic rendah/spiky. Pada throughput tinggi konstan, container atau VM reserved sering lebih ekonomis. Kita hitung presisi di episode 13.
#Modular Monolith: Kandidat yang Sering Dilupakan
Untuk mayoritas tim, modular monolith adalah titik awal terbaik: satu deployment (mudah dioperasikan) dengan boundary modul internal (siap diekstrak menjadi service saat benar-benar dibutuhkan). Aturan praktis industri yang layak dipegang: ekstrak ke microservices hanya jika kalian punya masalah scaling spesifik per domain atau lebih dari ±10 engineer yang saling menghambat.
#Trade-off Analysis: Cara Berpikir
Setiap opsi dinilai terhadap dimensi-dimensi yang penting bagi proyek kalian:
- Kompleksitas operasional — berapa hal baru yang harus di-monitor, di-deploy, diamankan?
- Skalabilitas — vertikal/horizontal, granularitas scaling per komponen.
- Kecepatan delivery — waktu sampai MVP dan kecepatan iterasi sesudahnya.
- Kebutuhan tim — skill yang harus ada (DevOps maturity, observability).
- Biaya — infrastruktur bulanan pada traffic target plus biaya kesempatan tim.
- Konsistensi data — transaksi lintas komponen: ACID mudah vs eventual consistency.
- Vendor coupling — seberapa dalam solusi terikat pada satu provider.
Latihan mental yang bagus: untuk tiap dimensi, tulis kalimat "kita dapat X dengan mengorbankan Y". Contoh nyata: "dengan event-driven kita dapat decoupling dan daya tahan lonjakan trafik, dengan mengorbankan konsistensi langsung dan kompleksitas tracing." Jika kalian tidak bisa menyebut konsekuensinya, kalian belum memahami opsi tersebut.
#Praktik: Weighted Scoring Matrix
Sekarang kita formalisasikan dengan alat kerja SA: weighted scoring matrix. Kembali ke studi kasus tiket event (50.000 user serentak, tim 6 engineer Node.js/PostgreSQL, budget ketat). Pertama tetapkan bobot sesuai requirement — inilah langkah yang paling sering dilewati dan paling menentukan:
Scaling elastis : 30 (NFR-02 lonjakan 50k user)
Kecepatan delivery : 25 (C-02 launch 90 hari)
Kemudahan operasi : 20 (tim 6 orang)
Biaya infrastruktur : 15 (C-01 budget <= 40 jt/bln)
Ekstensibilitas : 10 (fitur baru pasca-launch)Lalu nilai tiap opsi skala 1-10 per kriteria, kalikan bobot, jumlahkan:
| Kriteria (bobot) | Monolith | Modular Monolith | Microservices | Serverless |
|---|---|---|---|---|
| Scaling elastis (30) | 4 → 120 | 6 → 180 | 9 → 270 | 10 → 300 |
| Kecepatan delivery (25) | 8 → 200 | 8 → 200 | 3 → 75 | 7 → 175 |
| Kemudahan operasi (20) | 9 → 180 | 8 → 160 | 2 → 40 | 6 → 120 |
| Biaya (15) | 8 → 120 | 8 → 120 | 3 → 45 | 6 → 90 |
| Ekstensibilitas (10) | 3 → 30 | 7 → 70 | 9 → 90 | 8 → 80 |
| Total | 650 | 730 | 520 | 765 |
Hasil menarik: serverless unggul tipis, tetapi lihat baris kemudahan operasi — nilai 6 masih optimistis untuk debugging distributed system oleh 6 orang. Di sinilah judgment SA masuk: matrix memberi angka, kalian memberi konteks. Keputusan defensible yang umum untuk kasus ini: modular monolith dengan antrean event untuk modul pembelian (hybrid), karena lonjakan trafik terisolasi di satu titik panas saja. Skor hybrid bisa dihitung sendiri sebagai latihan — biasanya mengerucut di kisaran 750+.
Tip
Nilai dalam matrix boleh diperdebatkan — justru itu gunanya. Saat stakeholder tak setuju, minta mereka mengubah skor/bobot dengan alasan eksplisit. Matrix mengubah debat selera menjadi debat asumsi yang bisa diuji.
#Membekukan Keputusan: Architecture Decision Record
Keputusan yang sudah jatuh perlu direkam agar tidak dibuka-ulang tiap pergantian orang. Format ADR ringkas yang lazim:
# ADR-0001: Modular Monolith + Event Queue untuk Modul Pembelian
Tanggal : 2026-08-16
Status : Accepted
## Konteks
Tiket event dengan lonjakan 50k user serentak, tim 6 engineer,
launch 90 hari (lihat SDD bagian 2).
## Keputusan
Modular monolith (Node.js/PostgreSQL) dengan antrean event terpisah
untuk proses pembelian dan penerbitan tiket.
## Alternatif yang Ditolak
- Microservices penuh: skor operasional rendah untuk ukuran tim (ADR terpisah).
- Serverless penuh: risiko debugging dan cold-start pada jalur bayar.
## Konsekuensi
(+) Operasi sederhana, transaksi ACID utuh di inti.
(+) Modul purchase siap diekstraksi bila tim > 10 engineer.
(-) Perlu disiplin boundary modul; review arsitektur tiap sprint.Simpan ADR bernomor di repository — sepuluh menit menulis ini menghemat jam-jam debat enam bulan kemudian. Serangkaian ADR kalian juga akan menjadi materi utama saat architecture review di episode 24.
#Common Pitfalls
- Resume-driven architecture — memilih teknologi untuk CV tim, bukan untuk masalah. Uji sederhana: bisakah manfaatnya dijelaskan dengan angka requirement?
- Salah membaca matrix — skor adalah alat diskusi, bukan orakel; selalu cek sensitivitas: jika bobot bergeser 10 poin apakah ranking berubah?
- Lupa biaya migrasi keluar — opsi dengan lock-in terdalam harus diberi penalti eksplisit di kriteria vendor coupling.
- Keputusan tanpa tanggal review — tambahkan "revisit jika kondisi X berubah" di ADR; keputusan arsitektur bukan keputusan abadi.
#Penutup
Inti yang harus dibawa pulang:
- Tidak ada arsitektur terbaik universal — ada yang paling pas untuk requirement, tim, dan budget tertentu.
- Bandingkan minimal lima gaya: monolith, modular monolith, microservices, serverless, event-driven — dan jangan lupakan modular monolith sebagai default waras.
- Weighted scoring matrix membuat trade-off eksplisit: bobot diturunkan dari NFR, skor diperdebatkan terbuka.
- Bekukan keputusan dalam ADR: konteks, keputusan, alternatif yang ditolak, dan konsekuensi.
Di episode 5 selanjutnya kita turun ke level fisik: cloud solution design — reference architecture AWS/Azure/GCP, mendesain VPC multi-AZ yang benar, pola high availability standar industri, dan cara memakai Well-Architected Framework sebagai checklist desain. Sampai jumpa di episode 5!