Belajar Software Architect - Architectural Styles

#Pendahuluan

Setelah di episode 2 kita membangun fondasi architectural thinking — definisi arsitektur, quality attributes, dan hukum trade-off — pada episode ini kita naik ke tingkat architectural style: bentuk makro struktur sistem yang kalian pilih sebelum menulis satu baris kode pun.

Architectural style adalah pola umum bagaimana komponen diorganisir dan saling berkomunikasi. Analoginya seperti gaya arsitektur bangunan: rumah taman, apartemen, atau gedung bertingkat — semuanya bisa jadi tempat tinggal, tetapi biaya, kapasitas, dan cara merawatnya sangat berbeda. Memilih style adalah salah satu keputusan paling mahal untuk diubah (ingat uji "mahal diubah" dari episode 2), karena style menentukan cara tim bekerja, cara deploy, dan batas skalabilitas sistem selama bertahun-tahun.

#Apa Itu Architectural Style

Style menjawab dua pertanyaan struktural:

1. Bagaimana unit-unit besar sistem dibagi — satu unit monolitik, beberapa service, atau modul dalam satu deployment?
2. Bagaimana unit-unit itu berinteraksi — panggilan sinkron, pesan asinkron, atau tidak berinteraksi sama sekali?

Perhatikan bedanya dengan design pattern (episode 4): design pattern bekerja di level class/modul untuk masalah lokal; style bekerja di level sistem untuk struktur global. Keduanya saling melengkapi, bukan bersaing.

Empat style yang akan kita bahas mencakup mayoritas sistem produksi modern: layered, microservices, event-driven, dan modular monolith.

#Layered Architecture

Layered adalah style paling tua dan paling umum: kode dibagi menjadi lapisan horizontal, dan setiap lapisan hanya boleh memanggil lapisan di bawahnya.

┌──────────────────────────────┐
│ Presentation (API/UI)        │
├──────────────────────────────┤
│ Business Logic (domain)      │
├──────────────────────────────┤
│ Persistence (repository)     │
├──────────────────────────────┤
│ Database                     │
└──────────────────────────────┘

Kelebihannya nyata: sederhana, semua orang langsung paham, konvensi jelas, murah untuk tim kecil. Hampir semua framework populer (Spring MVC, Laravel, Rails, Next.js) secara default mendukung pola ini.

Kekurangannya juga nyata:

Sink hole anti-pattern layak digarisbawahi: jika 80% request di sistem kalian hanya lewat presentation → service → repository → SQL tanpa transformasi, maka lapisan-lapisan itu bukan arsitektur, melainkan birokrasi.

#Microservices Architecture

Microservices memecah sistem menjadi service-service kecil yang independen: punya database sendiri, bisa dideploy sendiri, dan dimiliki oleh tim berbeda.

[API Gateway]
     │
 ┌───┼────┬─────────┐
 ▼   ▼    ▼         ▼
Order Cart Payment Inventory   ← tiap service + DB sendiri

Kelebihan inti:

• Deploy independence — tim payment rilis tanpa menyentuh tim order.
• Skala selektif — hanya inventory service yang direplikasi saat flash sale.
• Isolasi kegagalan — recommendation down tidak menjatuhkan checkout.
• Autonomi tim — organisasi bisa berkembang mengikuti pemisahan service (Conway's Law bekerja untuk kalian).

Tetapi harga yang harus dibayar sering diremehkan:

• Kompleksitas terdistribusi — network latency, partial failure, konsistensi data lintas service.
• Operasional berat — butuh CI/CD matang, observability (tracing, logging terpusat), dan platform yang solid.
• Integrasi mahal — kontrak antar service harus dirawat; perubahan schema butuh koordinasi.
• Data consistency — tidak ada lagi transaksi ACID lintas modul; harus pakai saga/eventual consistency.

Richards & Ford menyebut microservices sebagai style dengan trade-off paling ekstrem: kekuatan terbesarnya (decoupling) sekaligus sumber masalah terbesar. Detail penuh kita bahas di episode 12.

#Event-Driven Architecture

Event-driven membalik arah komunikasi: komponen tidak saling memanggil, melainkan menerbitkan (publish) event yang didengarkan (subscribe) oleh pihak lain melalui broker (Kafka, RabbitMQ).

[Checkout Service] --publish--> [Broker/Kafka] --subscribe--> [Inventory]
                                              --subscribe--> [Email Service]
                                              --subscribe--> [Analytics]

Kelebihannya:

• Decoupling temporal — publisher tidak peduli subscriber hidup atau mati.
• Elasticity alami — tambah consumer baru tanpa mengubah producer.
• Throughput tinggi — cocok untuk aliran data besar (log, klik, transaksi).
• Audit trail — aliran event bisa direkam dan di-replay.

Kekurangannya jangan dianggap enteng:

• Alur sulit dilacak — tidak ada call stack; debugging butuh distributed tracing.
• Final consistency — data akhirnya konsisten, tetapi tidak instan.
• Event schema evolution — mengubah format event lama adalah mimpi buruk tanpa disiplin versioning.
• Dead letter & retry semantics — kegagalan consumer harus dirancang eksplisit.

Event-driven jarang berdiri sendiri; biasanya ia dikombinasikan sebagai gaya komunikasi di dalam microservices atau modular monolith. Episode 13 membahasnya tuntas termasuk Kafka dan event sourcing.

#Modular Monolith

Modular monolith adalah satu unit deploy dengan pembagian internal yang disiplin: modul-modul memiliki boundary jelas, interface publik, dan data sendiri-sendiri.

[Satu Deployment]
 ├── module: catalog      (public API + private impl)
 ├── module: ordering     (public API + private impl)
 ├── module: payment      (public API + private impl)
 └── module: inventory    (public API + private impl)

Poin kuncinya: dari luar terlihat seperti monolith biasa, tetapi dari dalam ia berperilaku seperti microservices yang "ditempel" sementara — modul tidak boleh mengakses tabel modul lain, komunikasi hanya lewat interface publik.

Mengapa style ini naik daun (dan menjadi tren kuat 2026)?

• Deployment sederhana seperti monolith: satu artefak, transaksi ACID lokal, debugging mudah.
• Boundary disiplin seperti microservices: modul bisa diekstrak menjadi service nanti tanpa rewrites.
• Biaya operasional rendah — tidak butuh mesh, gateway, dan armada pipeline untuk mulai.

Dua style lain yang perlu kalian kenali sekilas: pipeline architecture (data mengalir lewat tahapan filter — cocok untuk ETL dan compiler) dan microkernel/plugin architecture (core kecil + plugin — cocok untuk IDE dan browser). Keduanya spesifik domain, jarang jadi style utama aplikasi bisnis.

#Membandingkan Empat Style

Ringkasan trade-off berdasarkan quality attributes (skala relatif):

Tidak ada kolom yang menang semuanya — persis hukum trade-off dari episode 2. Style yang benar ditentukan oleh quality attributes mana yang paling penting bagi konteks kalian.

#Praktik: Memilih Style untuk Studi Kasus E-commerce

Mari terapkan pada studi kasus dari episode 2. Quality attributes prioritas kalian:

1. Availability tinggi di jalur checkout.
2. Performance: p99 read path di bawah 300 ms.
3. Consistency kuat di payment.
4. Scalability 10x untuk flash sale.
5. Deploy harian tanpa downtime.

Sekarang analisis konteksnya:

• Tim: 6 developer, belum punya platform engineering.
• Traffic: 500 ribu MAU, spike mingguan (bukan terus-menerus).
• Domain: e-commerce standar (catalog, order, payment) — cukup map, bukan kompleks.

Evaluasi cepat:

Microservices?
  → deploy independence & scale selektif cocok...
  → tapi: 6 developer, tanpa platform, butuh ACID payment
  → biaya operasional > manfaatnya. BUKAN sekarang.
 
Layered monolith?
  → simpel, tapi boundary longgar → scalability 10x ragu,
     deploy harian berisiko (semua tergabung). Kurang pas.
 
Event-driven penuh?
  → overkill untuk CRUD-dominan; konsistensi payment jadi sulit.
 
Modular monolith + event-driven internal?  ← PILIHAN
  → deployability tinggi, ACID lokal untuk payment,
     boundary modul = jalur migrasi nanti,
     event async untuk bagian non-kritis (email, analytics).

Keputusan ini sementara dan sadar: modular monolith hari ini dengan rencana evolusi ke services jika tim dan traffic bertumbuh — topik lengkap episode 15.

#Kesalahan Umum Memilih Style

• Fashion-driven choice — memilih microservices karena Netflix memakainya, bukan karena masalah kalian menuntutnya. Netflix punya ribuan engineer dan platform kelas dunia; konteks kalian hampir pasti berbeda.
• All-in satu style — sistem nyata hampir selalu hibrida: modular monolith dengan komunikasi event-driven di beberapa bagian adalah kombinasi yang sah.
• Mengabaikan ukuran tim — Conway's Law tidak bisa dilanggar, hanya bisa didesain. Microservices untuk 4 developer menghasilkan distributed monolith yang terburuk dari dua dunia.
• Lupa biaya operasional — setiap service menambah kebutuhan monitoring, on-call, dan pipeline. Hitung biaya "tak terlihat" ini sebelum memutuskan.
• Tidak punya exit strategy — style yang dipilih tanpa memikirkan cara keluar darinya akan mengunci kalian selamanya.

#Penutup

Inti yang harus dibawa pulang dari episode ini:

• Architectural style menentukan struktur makro: bagaimana sistem dibagi dan bagaimana komponennya berinteraksi.
• Layered: sederhana dan familiar, tetapi rawan sink hole dan scalability seluruh unit.
• Microservices: deploy independence dan scale selektif, dengan biaya kompleksitas terdistribusi yang tinggi.
• Event-driven: decoupling temporal dan throughput tinggi, dengan final consistency dan tracing yang menantang.
• Modular monolith: sweet spot banyak tim 2026 — kesederhanaan monolith dengan disiplin boundary microservices.
• Pilihan style = fungsi dari quality attributes prioritas + konteks tim + biaya operasional, bukan tren.

Di episode 4 selanjutnya kita turun satu level: design patterns & principles — SOLID, pattern GoF yang relevan bagi architect, dan domain-driven design sebagai alat menentukan boundary. Sampai jumpa!