Belajar Software Architect - Quality Attributes Engineering

#Pendahuluan

Setelah di episode 4 kita menurunkan arsitektur ke level desain — SOLID, pattern GoF, dan bounded context DDD — pada episode ini kita kembali ke quality attributes, tetapi kali ini secara engineering: dari kata-kata seperti "harus cepat" menjadi angka yang bisa diverifikasi.

Ini keterampilan paling membedakan architect dari developer senior. Developer mengukur keberhasilan dengan "fiturnya jalan"; architect mengukur dengan atribut non-fungsional yang dituntut. Dan karena semua attribute saling berebut (hukum trade-off episode 2), kalian butuh format standar untuk menyatakannya agar bisa dinegosiasikan dengan stakeholder dan diverifikasi oleh sistem.

#Quality Scenario: Format Terukur

SEI (Software Engineering Institute, CMU) menyediakan format enam bagian untuk setiap persyaratan kualitas:

Tanpa response measure, persyaratan kualitas tidak bisa diuji — ia hanya opini. "Sistem harus cepat" tidak berarti apa-apa; "p99 read path ≤ 300 ms pada 500 rps" adalah kontrak yang bisa dilanggar, dipantau, dan dievaluasi.

#Performance

Performance tentang kecepatan merespons satu request. Metrik utamanya:

• Latency percentiles — p50, p95, p99. Rata-rata menyesatkan karena outlier pengguna berat justru tersembunyi; p99 memaksa kalian peduli pada 1% terlambat.
• Throughput — request per detik yang bisa ditangani pada target latency.
• Resource utilization — CPU/memori per unit kerja.

Tactics utama:

Reduce demand   → lazy load, pagination, field selection
Manage resource → connection pooling, thread pool sizing
Introduce cache → CDN, app-level cache, buffer
Process async   → antrikan pekerjaan berat, balik cepat

Setiap tactic punya harga: cache menambah masalah invalidasi, async menambah final consistency, pooling menambah tuning. Tidak ada yang gratis.

#Scalability

Scalability tentang kemampuan menangani beban bertambah — bukan kecepatan satu request.

#Vertical vs Horizontal

Vertical (naikkan spek mesin) mudah tapi mentok dan single point of failure. Horizontal (tambah instance) tak terbatas teoretis tapi menuntut statelessness: sesi tidak boleh menempel di memori satu instance — simpan di Redis atau token stateless.

#Partitioning & Sharding

Ketika satu database mentok, pecahkan data:

• Range-based — order Januari–Maret di shard A. Sederhana tapi rawan hot spot.
• Hash-based — distribusi merata, tapi resharding mahal.
• Directory/lookup — fleksibel, tambah satu hop pencarian.

Aturan emasnya: pilih partition key yang membuat query umum menyentuh satu partisi, bukan menyapu semuanya.

#Load Balancing

L4 (transport) cepat tapi buta isi request; L7 (application) paham URL/header sehingga bisa routing cerdas dan health check granular. Kombinasi keduanya standar di produksi.

#Reliability & Availability

Availability diukur dalam nines — dan tabel ini wajib melekat di kepala:

Insight penting: naik dari 99% ke 99,9% bisa dicapai dengan disiplin engineering biasa; naik ke 99,99% melipatgandakan biaya (multi-region, replikasi, on-call). Inilah kenapa target harus eksplisit.

Reliability lebih luas dari availability — sistem bisa "hidup" tapi salah hasil. Kuncinya redundancy + failure detection + failover otomatis, plus dua metrik pemulihan: MTBF (berapa sering rusak) dan MTTR (berapa lama pulih). Arsitek modern sering mengoptimalkan MTTR dulu karena lebih murah daripada mengejar MTBF sempurna.

#Security

Security scenario juga bisa diformat: stimulus = percobaan akses tanpa otorisasi, response measure = 100% ditolak + tercatat audit dalam ≤ 1 detik.

Tactics inti:

• Authentication vs authorization — verifikasi identitas, lalu batasi akses. Jangan tertukar.
• Defense in depth — validasi di edge, di service, dan di database. Satu lapisan pasti bocor.
• Encryption — in transit (TLS) dan at rest. Bukan opsional di 2026.
• Audit trail — siapa melakukan apa, immutable, retensi jelas.
• Least privilege — setiap komponen hanya punya izin minimum.

Episode 10 membahas security architecture tuntas termasuk threat modeling; di sini cukup dipahami sebagai attribute yang ikut dinegosiasikan dan diukur.

#Maintainability, Testability, Deployability

Tiga attribute yang sering diremehkan padahal menentukan kecepatan tim jangka panjang:

• Maintainability — biaya modifikasi. Indikator: waktu implementasi fitur serupa, tingkat coupling antar modul.
• Testability — kemudahan menguji. Indikator: persentase kode yang bisa di-test tanpa environment penuh; kontrol & observabilitas internal.
• Deployability — kemudahan rilis. Indikator: frekuensi deploy, lead time, tingkat rollback.

Industri modern mengukurnya via DORA metrics (deployment frequency, lead time for changes, change failure rate, MTTR). Menariknya, ketiga attribute ini hampir selalu dilayani oleh keputusan yang sama: modularitas yang baik, automation pipeline, dan infrastruktur reproducible.

#Praktik: Quality Scenario Flash Sale

Mari tulis scenario lengkap untuk kasus paling kritis studi kasus kita — checkout saat flash sale:

scenario: checkout-saat-flash-sale
source: pengguna menekan tombol bayar
stimulus: POST /orders dengan item flash sale
artifact: ordering module + payment integration
environment: traffic 10x normal, cache hangat
response:
  - order dibuat dengan status PENDING_PAYMENT
  - stok direservasi atomik (tidak oversell)
  - charge ke payment gateway dipicu
response_measures:
  availability: jalur checkout ≥ 99.95% selama event
  latency: p99 ≤ 800 ms sampai respons diterima user
  correctness: oversell = 0; double-charge = 0
  degradation: jika inventory lambat, tolak dengan pesan jelas
                dalam ≤ 2 detik, jangan diam-diam hang

Perhatikan baris terakhir — graceful degradation adalah response yang dirancang, bukan kebetulan. Sistem yang baik saat beban puncak bukan yang tidak pernah kesulitan, melainkan yang kesulitannya terlihat rapi bagi pengguna.

Dari scenario inilah tactics dipilih: reservasi stok atomik di database (consistency), async charge dengan idempotency key (latency + correctness), circuit breaker ke gateway (degradation), autoscaling dengan headroom 2x (availability).

#Kesalahan Umum

• Mengukur average, bukan percentile — p50 indah, p99 kiamat. User tidak hidup di rata-rata.
• Target tanpa kondisi beban — "300 ms" pada jam sepi tidak berarti apa-apa; selalu cantumkan environment.
• Mengejar nines tanpa biaya — setiap sembilan tambahan melipatgandakan kompleksitas; negosiasikan, jangan asal janji.
• Attribute disembunyikan sampai produksi — kalau tidak ditulis sebagai scenario, ia baru akan dibahas saat insiden pertama.
• Semua attribute prioritas maksimal — kalau semuanya nomor satu, artinya tidak ada yang nomor satu. Paksa urutan.

#Penutup

Inti yang harus dibawa pulang:

• Quality scenario (source, stimulus, artifact, environment, response, response measure) mengubah opini menjadi kontrak terukur.
• Performance pakai percentile, scalability pakai horizontal + partitioning, reliability pakai nines + MTBF/MTTR — masing-masing dengan tactics dan harganya.
• Maintainability/testability/deployability diukur lewat DORA metrics dan dilayani oleh modularitas + automation.
• Setiap tactic punya harga — dokumentasikan trade-off, buang hanya ke stakeholder bersama scenarionya.
• Studi kasus kini punya scenario flash sale lengkap dengan measures yang akan dipakai ulang saat evaluasi arsitektur di episode 22.

Di episode 6 selanjutnya kita bahas architecture documentation — model C4 untuk menggambar arsitektur secara efektif dan Architecture Decision Records untuk mencatat keputusan-keputusan yang lahir dari scenario-scenario ini, termasuk praktik menulis ADR pertama untuk studi kasus kita. Sampai jumpa!