Belajar Software Architect - Cost & Efficiency Architecture

#Pendahuluan

Setelah di episode 16 kalian merancang resilience menyeluruh — timeout budget, circuit breaker, bulkhead, hingga error budget — pada episode ini kita bahas dimensi yang jarang muncul di diagram arsitektur tetapi selalu muncul di rapat direksi: biaya.

Cost-efficiency adalah quality attribute yang sah, sama seperti performance. Keputusan arsitektur kalian secara langsung menentukan tagihan cloud bulanan — dan sebaliknya, struktur biaya menentukan pilihan desain yang terjangkau. Architect yang tidak bisa menjawab "berapa biaya per order sistem ini" akan kehilangan argumen di meja bisnis; architect yang bisa, berubah dari pemakai budget menjadi mitra strategis.

#FinOps: Disiplin Biaya Cloud

FinOps adalah praktik mengelola biaya cloud dengan kolaborasi finance-engineering-product. Tiga fasa kerjanya:

Informate : tagihannya transparan & dialokasikan per tim/service
Optimize  : tindakan efisiensi berdasarkan data tersebut
Operate   : kebijakan & target biaya jadi bagian operasi rutin

Prasyarat teknisnya satu: alokasi per service lewat tagging disiplin (service=inventory, env=prod) sehingga tagihan bisa dipotong per modul. Tanpa itu, semua diskusi biaya adalah perang opini tentang siapa yang boros.

Perhatikan posisi ini bagi architect: FinOps bukan pekerjaan tim finance semata — keputusan struktural (managed DB vs self-hosted, container vs serverless, replika baca tambahan) adalah keputusan arsitektur yang konsekuensi finansialnya berbulan-bulan.

#Unit Economics Sistem

Angka paling penting bukan total tagihan, melainkan biaya per unit bisnis: per order, per request, per pengguna aktif.

Mengapa? Karena ia membuat biaya proporsional terhadap nilai:

Infra bulanan      : $4.200
Order bulanan      : 120.000
Biaya per order    : $0.035
 
Jika margin/order = $2 → infra 1.75% dari revenue ✓ sehat
Jika margin/order = $0.05 → infra 70% margin ✗ desain salah

Kasus kedua menuntut keputusan arsitektur (efisiensi), bukan sekadar hemat-hemat listrik: mungkin caching kurang agresif, mungkin jalur analitik real-time mahal tak bernilai. Unit economics mengubah "tagihan besar" menjadi diagnosis terarah.

Perilaku skalanya juga penting: biaya ideal bertumbuh sub-linear terhadap trafik (cache hit naik, instance tetap). Jika biaya naik linear 1:1 dengan traffic, arsitektur kalian sedang membeli setiap pengguna dua kali.

#Trade-off Biaya Model Komputasi

Lanjutan tabel episode 14, kini dengan lensa biaya:

Aturan kasarnya: serverless menang saat duty-cycle rendah (<30%), container menang saat tinggi (>60%). Studi kasus kita sudah konsisten: core checkout steady → container; image resize sporadis → FaaS.

Dua taktik efisiensi compute yang sering terlupakan:

• Scale-to-minimal di jam sepi — trafik e-commerce Indonesia turun 80% antara 02.00-06.00; autoscaling yang benar mengejar itu, bukan hanya menaik.
• Spot untuk non-kritis — batch laporan, CI runner, worker analytics: diskon 60-90% dengan syarat toleran preemption.

#Storage & Data Transfer: Biaya yang Bersembunyi

Compute terlihat; storage dan transfer sering mengejutkan:

#Data Lifecycle

Data panas jarang lebih dari 5% volume total. Tiering otomatis menyelamatkan puluhan persen: object storage hot → infrequent access (90 hari) → archive (1 tahun) untuk audit log dan snapshot backup lama. Database pun sama — partisi lama bisa dipindah ke penyimpanan murah tanpa hilang.

#Egress: Pajak Keluar Awan

Trafik keluar (egress) dikenakan mahal — dan pola arsitektur menentukannya:

Anti-pola : App cloud → DB cloud → API user lain-cloud (egress 2x)
Pola baik : Komputasi dekat sumber data, kirim hasil ringkas

Konsekuensi desainnya nyata: agregasi di tempat data hidup, CDN menyerap egress konten statis dengan harga jauh lebih murah, dan integrasi B2B besar pertimbangkan region/data-transfer agreement.

#Praktik: Model Biaya Studi Kasus

Mari hitung kasar infrastruktur bulanan e-commerce kita (harga indikatif):

kompute_k8s:
  baseline: {pods: 6, vcpu_total: 6, gb_total: 12}
  flash_sale_peak: {pods: 30, jam_per_bulan: 8}
  estimasi: "$420/bln (rata-rata termasuk pre-scale)"
database_postgres:
  primary: {vcpu: 4, ram_gb: 16, storage_gb: 500}
  replica_read: 1x primary
  estimasi: "$520/bln managed"
redis_cache: {gb: 8, ha: true, estimasi: "$95/bln"}
kafka_managed: {partisi: 12, retensi_30d, estimasi: "$180/bln"}
object_storage_cdn:
  produk_media_tb: 1.2
  log_arsip_tb: 2.0
  egress_tb: 3.5
  estimasi: "$210/bln"
observability:
  logs_gb_hari: 25, trace_sampled: "10%"
  estimasi: "$140/bln"
total_estimasi: "~$1.565/bulan"
unit_economics:
  order_per_bulan: 120000
  cost_per_order: "$0.013"
margin_check: "infra ≈ 0.9% dari GMV -> sehat"

Bandingkan dengan skenario alternatif yang dievaluasi dan ditolak, beserta alasannya — karena itulah nilai dokumen ini:

Multi-AZ HA full (replica sync + failover auto)
  +$380/bln -> DITAHAN: RPO/RTO scenario ep5 belum
  menuntutnya; backup PITR cukup sementara ini
 
Kafka self-hosted di spot instances
  -$120/bln -> DITOLAK: on-call effort & risiko data
  loss melebihi penghematannya
 
Serverless untuk core API
  ±sama/bln pada trafik kini -> DITOLAK: cold start
  jalur uang + kehilangan pre-scaling deterministik ep11

Model biaya ini juga menjadi alat prediksi: jika traffic 2x, mana yang naik linear (compute), sub-linear (cache hit rate naik), atau step-function (butuh replica baru)? Jawabannya memberi tahu finance kapan anggaran berubah — bukan saat tagihan datang sebagai kejutan.

#Kesalahan Umum

• Over-provision permanen untuk peak tahunan — kapasitas flash sale dibayar 720 jam/bulan padahal dibutuhkan 8 jam; pre-scaling dinamis (episode 11) justru lebih murah.
• Mengabaikan egress sampai tagihan datang — integrasi data-heavy lintas provider adalah kebocoran senyap.
• Serverless pada throughput steady — biaya per-request melampaui container hangat; hitung break-even point-nya, jangan asumsi.
• Environment non-produksi 24/7 — staging dengan spesifikasi produksi penuh adalah duplikat mahal yang jarang dipakai.
• Observability tanpa sampling — logging verbose penuh di produksi bisa melampaui biaya aplikasinya sendiri; sample trace, level-aware logs, retensi bertingkat.
• Hemat pada hal salah — meniadakan replica DB untuk hemat $100 lalu membayar insiden availability ratusan juta rupiah; efisiensi tidak boleh menggerus janji SLO.

#Penutup

Inti yang harus dibawa pulang:

• FinOps = siklus informate-optimize-operate; prasyaratnya alokasi biaya per service via tagging.
• Unit economics (biaya per order) mengubah tagihan menjadi diagnosis dan bahasa bersama dengan bisnis.
• Model komputasi punya titik balik biaya: serverless untuk sporadis, container untuk steady, spot untuk batch.
• Storage butuh lifecycle tiering; egress membentuk penempatan komputasi.
• Studi kasus kini punya cost model konkret ~$1,56 ribu/bulan, $0,013 per order, plus daftar alternatif yang ditolak beserta alasan terukurnya.
• Efisiensi berhenti di garis SLO: hemat yang merusak reliability bukan penghematan, melainkan hutang insiden.

Di episode 18 selanjutnya kita perdalam fondasi zero trust dari episode 10: zero trust software — identity-based design, mutual TLS dan service identity, least privilege end-to-end, hingga bagaimana studi kasus kita membangunnya tanpa service mesh sejak hari pertama. Sampai jumpa!