Belajar Cloud Architect - Design Trade-offs & Decision Making

#Pendahuluan

Di episode 2 kita belajar bahwa framework arsitektur memberi pillar untuk menilai desain. Tetapi ada satu kenyataan yang framework tidak pernah sebut eksplisit: pillar-pillar itu sering bertentangan. Keamanan yang ketat menambah latency. Reliability tinggi menambah biaya. Performance optimal menambah kompleksitas. Seorang arsitek tidak bisa memaksimalkan semuanya.

Inilah inti dari pekerjaan arsitek: membuat trade-offs secara sadar, lalu mendokumentasikannya. Episode ini membahas tiga trade-off paling umum dan alat bernama ADR (Architecture Decision Record) untuk merekam keputusan agar bisa dipertanggungjawabkan di kemudian hari.

#Cost vs Reliability vs Performance

#Segitiga yang Tidak Pernah Seimbang

Sering digambarkan sebagai "tidak bisa dapat ketiganya sekaligus". Concurrency di produksi memperjelas ini:

Skema	Cost	Reliability	Performance
Single region, single AZ	Rendah	Rendah	Tinggi
Multi-AZ, RDS dengan standby	Sedang	Sedang	Tinggi
Multi-region active-active	Tinggi	Tinggi	Tinggi
Serverless on-demand	Rendah (0 saat idle)	Sedang	Sedang (cold start)

Contoh kasus nyata: aplikasi batch analytics yang berjalan 1 jam tiap malam. Membeli VM reserved 24/7 untuk workload 1 jam adalah pemborosan besar — serverless atau instance spot jauh lebih masuk akal. Sebaliknya, core transaction system dengan SLA 99.99% tidak bisa diletakkan di satu AZ.

#Pertanyaan Kunci

Sebelum memilih, tanyakan:

Berapa kerugian per jam downtime? Ini menentukan budget reliability (episode 8).
Berapa nilai satu detik latency? Ini menentukan investasi performance.
Berapa biaya yang bisa dibayar? Ini batas atas semua keputusan.

Arsitek menghitung ketiganya, bukan menerka. Data bisnis ini menentukan trade-off secara objektif.

#Latency vs Consistency

Sistem terdistribusi menghadapi pilihan sulit antara kecepatan dan konsistensi data — dijelaskan secara klasik oleh CAP theorem: saat partisi jaringan terjadi, sistem harus memilih antara consistency (semua node melihat data sama) dan availability (semua node tetap melayani). Konsep yang lebih halus adalah trade-off antara latency dan consistency bahkan dalam kondisi normal.

#Contoh Nyata

Kasir retail: data stok harus konsisten — dua kasir tidak boleh menjual barang terakhir yang sama. Pilih konsistensi; terima latency lebih tinggi.
Feed notifikasi: tidak apa-apa jika notifikasi terlihat 5 detik kemudian. Pilih latency rendah dengan eventual consistency.
E-commerce katalog: produk bisa di-cache dengan CDN (stale beberapa menit) karena konsistensi katalog tidak sensitif waktu.

Spektrum latency vs consistency

Strong consistency (RDBMS, sync replication)
    └─ latency tinggi, data selalu sama
Eventual consistency (CDN, cache, noSQL)
    └─ latency rendah, data sama setelah beberapa saat

Tidak ada jawaban universal — jawabannya bergantung pada domain bisnis. Inilah alasan "memilih database" bukan soal favorit, melainkan soal membaca kebutuhan konsistensi (episode 5).

#Monolith vs Microservices

#Bukan Soal Modern

Kesalahan terbesar: menganggap microservices selalu lebih baik. Sebenarnya ada spektrum:

Aspek	Monolith	Microservices
Deployment	Satu unit, sederhana	Banyak unit, kompleks
Scaling	Seluruh app	Per service
Kecepatan rilis tim besar	Lambat (bottleneck)	Cepat per tim
Operasional	Sederhana	Mahal (observability, jaringan)
Cocok untuk	Tim kecil, domain sederhana	Tim besar, domain kompleks

Warning

Aturan praktis: mulai dari monolith, pisah menjadi microservices hanya ketika batas domain jelas dan tim sudah cukup besar. "Microservices-first" tanpa kebutuhan nyata adalah sumber biaya operasional dan kompleksitas yang tidak perlu — kebalikan dari trade-off reasoning.

#Modular Monolith sebagai Jalan Tengah

Banyak arsitek memilih modular monolith: kode satu aplikasi, tapi dipisahkan ke modul dengan batas domain yang tegas. Deployment tetap sederhana seperti monolith, tetapi struktur memungkinkan dipisah nanti saat benar-benar butuh. Ini trade-off paling rasional untuk mayoritas organisasi.

#ADR: Mendokumentasikan Keputusan

#Kenapa ADR

Keputusan arsitektur adalah aset paling berharga sekaligus paling cepat hilang. Enam bulan kemudian, tim bertanya "kenapa kita pakai pattern ini?" — dan tidak ada yang ingat. ADR (Architecture Decision Record) menjawabnya: dokumen singkat yang merekam konteks, keputusan, dan konsekuensinya.

#Struktur ADR Sederhana

ADR-001: Pilih managed database dibanding self-managed

# ADR-001: Managed Database dibanding Self-Managed
 
## Status
Accepted
 
## Konteks
Aplikasi butuh PostgreSQL untuk data transaksional.
Tim kecil tanpa DBA penuh, target SLA 99.9%.
 
## Keputusan
Gunakan RDS (managed) daripada PostgreSQL self-hosted.
 
## Konsekuensi
Positif: backup otomatis, failover, patch terkelola.
Negatif: biaya lebih tinggi, kontrol tuning terbatas.
Alternatif yang dipertimbangkan: PostgreSQL di EC2, Aurora.

Hanya 15-30 baris, cukup untuk menyimpan konteks dan alasan. Simpan ADR di repository yang sama dengan kode — versioning otomatis, review bisa dilakukan seperti pull request. Episode 23 akan membahas governance ADR di level organisasi.

#Penutup

Inti yang harus dibawa pulang:

Trade-off adalah inti pekerjaan arsitek; pillar framework sering bertentangan satu sama lain.
Cost vs reliability vs performance: hitung nilai bisnisnya, jangan menerka.
Latency vs consistency: jawabannya bergantung domain — tidak ada jawaban universal.
Monolith vs microservices: mulai monolith, modular, pisah saat benar-benar butuh.
Dokumentasikan setiap keputusan dengan ADR — konteks, keputusan, konsekuensi.

Di episode 4 selanjutnya kita akan membahas compute & serverless architecture — memilih antara VM, container, dan serverless, pola arsitektur masing-masing, serta cara mendesain pilihan compute yang optimal. Sampai jumpa di episode 4!