Kurikulum: Belajar Architectural Thinking dari Nol

Untuk siapa: Siapapun yang belum pernah memikirkan “bagaimana sebuah sistem dirancang” sebelumnya.
Pendekatan: Seperti sekolah — mulai dari yang paling dasar, tidak ada yang dilewat, tidak ada yang diasumsikan sudah diketahui.
Catatan guru: Rasa bingung itu normal. Bukan tanda bodoh. Itu tanda kamu sedang belajar sesuatu yang baru.

Sebelum Mulai: Apa Itu “Arsitektur”?

Bayangkan kamu ingin membangun rumah.

Kamu tidak langsung ambil batu bata dan mulai menumpuk. Kamu butuh seseorang yang duduk dulu, berpikir, menggambar denah: pintu di mana, dapur di mana, bagaimana aliran udara, bagaimana kalau ada gempa. Orang yang berpikir seperti ini adalah arsitek.

Di dunia perangkat lunak, masalahnya sama. Sebelum nulis satu baris kode pun, ada seseorang yang harus berpikir:

• Bagaimana komponen-komponen sistem ini saling terhubung?
• Apa yang terjadi kalau ada 1 juta pengguna masuk sekaligus?
• Bagaimana kalau server tiba-tiba mati?
• Di mana data disimpan, dan siapa yang boleh mengaksesnya?

Orang yang berpikir seperti ini disebut software architect, dan cara berpikirnya disebut architectural thinking.

Kamu tidak harus punya jabatan “arsitek” untuk belajar ini. Setiap programmer yang ingin membuat sistem yang tidak berantakan perlu memiliki kemampuan ini.

Bagian 1: Fondasi — Cara Berpikir Seorang Arsitek

Sebelum belajar “apa yang dirancang”, kamu harus belajar “bagaimana cara berpikir dalam merancang”.

Bab 1.1 — Berpikir dalam Sistem (System Thinking)

Apa itu sistem?

Sistem adalah kumpulan komponen yang bekerja sama untuk menghasilkan sesuatu.

Tubuh manusia adalah sistem: jantung, paru-paru, otak, darah — semuanya bekerja bersama. Kalau satu rusak, yang lain ikut terdampak.

Aplikasi WhatsApp adalah sistem: ada HP kamu, ada jaringan internet, ada server WhatsApp, ada database tempat pesan disimpan, ada server lain yang mengirim notifikasi. Semuanya harus bekerja bersama agar pesan kamu sampai dalam 1 detik.

Cara berpikir sistem: Input → Proses → Output

Apapun sistemnya, selalu ada tiga hal ini:

INPUT  →  PROSES  →  OUTPUT

Contoh sederhana — mesin ATM:

• Input: Kartu ATM, PIN, jumlah uang yang diminta
• Proses: Verifikasi identitas, cek saldo, kurangi saldo
• Output: Uang keluar, struk, notifikasi di HP

Latihan berpikir: Coba ambil satu aplikasi yang kamu pakai sehari-hari (misalnya Go-Food). Apa inputnya? Apa prosesnya? Apa outputnya? Kalau kamu bisa menjawab itu, kamu sudah mulai berpikir seperti arsitek.

Mengapa ini penting?

Karena banyak programmer yang langsung “menyelam” ke detail teknis tanpa pernah bertanya: sistem ini sebenarnya mau ngapain? Hasilnya? Kode yang ditulis dengan semangat, tapi tidak menjawab masalah yang benar.

Bab 1.2 — Trade-off: Tidak Ada yang Sempurna

Konsep paling penting dalam arsitektur

Ini mungkin pelajaran terpenting di seluruh kurikulum ini, jadi baca pelan-pelan.

Dalam dunia arsitektur, tidak ada solusi yang sempurna. Setiap pilihan selalu ada harga yang harus dibayar.

Ini disebut trade-off: kamu mendapat sesuatu, tapi kamu harus menyerahkan sesuatu yang lain.

Contoh yang mudah dipahami

Kamu mau pergi dari Jakarta ke Surabaya.

Tidak ada satu pun yang “terbaik secara mutlak”. Yang terbaik tergantung konteks: kamu punya uang berapa? Waktunya mendesak? Sendirian atau berdua?

Trade-off di sistem perangkat lunak

Contoh: kamu ingin membuat aplikasi toko online.

Kecepatan vs Akurasi Data

Bayangkan ada dua desain:

• Desain A: Setiap kali pengguna membuka halaman produk, sistem langsung cek stok terbaru ke database. Data selalu akurat, tapi lambat.
• Desain B: Stok di-cache (disimpan sementara), halaman terbuka sangat cepat, tapi bisa saja data stok sudah berubah tanpa pengguna tahu.

Mana yang benar? Tergantung. Kalau produknya barang langka yang cepat habis, pilih Desain A. Kalau produknya buku yang stoknya ribuan, Desain B mungkin cukup.

Seorang arsitek yang baik tidak mencari solusi sempurna. Ia mencari solusi yang trade-off-nya paling bisa diterima untuk konteks tersebut.

Cara berlatih

Setiap kali kamu membuat keputusan teknis, biasakan tanya: “Apa yang aku korbankan dengan pilihan ini?” Kalau tidak bisa menjawab, berarti kamu belum benar-benar memahami pilihanmu.

Bab 1.3 — Separation of Concerns: Pisahkan Tanggung Jawab

Analogi sederhana

Di sebuah restoran, ada pembagian tugas yang jelas:

• Koki fokus memasak. Dia tidak perlu tahu meja mana yang memesan.
• Pelayan fokus melayani tamu. Dia tidak perlu tahu resep masakannya.
• Kasir fokus menghitung tagihan. Dia tidak perlu tahu cara memasak.

Bayangkan kalau semua dilakukan oleh satu orang. Kacau, bukan?

Di dunia perangkat lunak

Separation of concerns artinya: setiap bagian dari sistem hanya punya satu tanggung jawab, dan tidak mencampuri urusan bagian lain.

Contoh aplikasi yang buruk:

// Satu fungsi yang melakukan segalanya — ini masalah
function klikTombelBeli() {
    tampilkanLoading();
    ambilDataPengguna();
    cekStok();
    hitungHarga();
    prosesPayment();
    kirimEmail();
    updateDatabase();
    sembunyikanLoading();
    tampilkanPesanSukses();
}

Fungsi ini terlalu tahu terlalu banyak hal. Kalau sistem email bermasalah, seluruh proses pembelian ikut gagal. Kalau kamu mau ganti cara pembayaran, kamu harus bongkar fungsi ini yang sudah penuh dengan hal-hal lain.

Contoh yang lebih baik: pisahkan setiap tanggung jawab ke modul/komponen yang berbeda, sehingga perubahan di satu tempat tidak merusak tempat lain.

Ini bukan hanya soal kerapian kode. Ini soal kemampuan sistem untuk bertahan saat ada perubahan.

Bab 1.4 — Scalability: Bagaimana Kalau Pengguna Bertambah Banyak?

Mulai dengan pertanyaan yang sering diabaikan

Bayangkan kamu membuat aplikasi absensi untuk satu kantor, 50 orang. Berjalan lancar.

Lalu perusahaanmu merger. Sekarang ada 5.000 orang yang harus absen lewat aplikasi yang sama, di waktu yang sama (jam 8 pagi). Apakah aplikasimu akan kuat? Atau akan crash?

Inilah pertanyaan tentang scalability — kemampuan sistem untuk berkembang seiring bertambahnya beban.

Dua cara scale

Vertical Scaling (Scale Up) — membuat satu mesin lebih kuat.

Analoginya: kamu punya satu tukang bakso yang bisa melayani 50 mangkok per jam. Kamu ganti dia dengan tukang bakso yang lebih cepat, bisa 200 mangkok per jam.

• ✅ Mudah dilakukan, tidak perlu ubah cara kerja sistem
• ❌ Ada batasnya — komputer paling canggih pun punya batas kemampuan
• ❌ Mahal

Horizontal Scaling (Scale Out) — menambah jumlah mesin.

Analoginya: daripada satu tukang bakso yang super cepat, kamu rekrut 4 tukang bakso biasa. Total tetap bisa 200 mangkok per jam.

• ✅ Tidak ada batas teoritis — bisa tambah terus
• ✅ Lebih murah dalam jangka panjang
• ❌ Lebih kompleks — siapa yang mengatur antrian ke tukang bakso mana? (Ini yang nanti disebut load balancer)

Yang perlu diingat

Scalability bukan sesuatu yang bisa “ditambahkan belakangan” dengan mudah. Sistem yang sejak awal tidak dirancang untuk scale, akan sangat susah di-scale nanti. Seperti rumah yang tidak dirancang untuk ditambah lantai — bisa saja ditambah, tapi risikonya besar.

Bab 1.5 — Networking: Bagaimana Komputer-komputer Berbicara?

Kamu mungkin tidak perlu jadi ahli jaringan, tapi kamu harus tahu ini

Setiap sistem modern melibatkan lebih dari satu komputer. Agar mereka bisa bekerja sama, mereka harus bisa berkomunikasi. Komunikasi ini terjadi lewat jaringan.

HTTP — Bahasa yang dipakai aplikasi web

HTTP adalah cara browser kamu “berbicara” dengan server.

Cara kerjanya sangat sederhana: Tanya-Jawab.

1. Browser kamu bertanya (Request): “Hei server, tolong berikan saya halaman youtube.com”
2. Server menjawab (Response): “Oke, ini dia, statusnya 200 (berhasil)”

Kalau server tidak menemukan halaman itu, jawabannya: “404 — Tidak ditemukan.”

Kamu pasti pernah lihat angka-angka seperti 404, 500, 200. Itu adalah status code — cara server memberitahu hasilnya.

DNS — Buku telepon internet

Setiap komputer di internet punya “alamat” berupa angka, disebut IP address. Contoh: 142.250.185.14.

Tapi kamu tidak pernah mengetik angka itu. Kamu mengetik google.com.

DNS adalah sistem yang menerjemahkan google.com menjadi 142.250.185.14. Seperti buku telepon yang menerjemahkan nama ke nomor telepon.

TCP/IP — Aturan dasar pengiriman data

Bayangkan kamu mengirim buku setebal 500 halaman lewat pos. Kamu tidak bisa kirim 500 halaman dalam satu amplop. Jadi kamu potong-potong jadi 50 paket, masing-masing 10 halaman, lalu kirim satu per satu.

TCP/IP adalah sistem yang mengatur cara memotong data, mengirimkannya, dan menyusunnya kembali di tujuan — bahkan kalau paket-paketnya tiba dalam urutan yang berbeda.

Bab 1.6 — Database: Di Mana Data Disimpan?

Tanpa database, tidak ada yang tersimpan

Bayangkan kamu membuat aplikasi catatan. Kamu tulis catatan, tutup aplikasinya, buka lagi — catatannya hilang. Kenapa? Karena tidak ada database.

Database adalah tempat menyimpan data secara permanen, sehingga bisa diakses lagi di masa depan.

SQL Database (Relasional) — Data yang terstruktur rapi

SQL database menyimpan data dalam bentuk tabel, seperti spreadsheet Excel.

Contoh tabel pengguna:

Contoh tabel pesanan:

Tabel pesanan terhubung ke tabel pengguna lewat kolom pengguna_id. Inilah arti kata “relasional” — data saling berelasi.

Cocok untuk: data yang terstruktur, butuh konsistensi tinggi (keuangan, e-commerce, sistem medis).

NoSQL Database — Data yang lebih fleksibel

Bayangkan kamu menyimpan data profil pengguna. Pengguna A punya nomor telepon, pengguna B tidak. Pengguna C punya 3 alamat, pengguna D tidak punya alamat sama sekali.

Di SQL, ini merepotkan karena kamu harus siapkan kolom untuk semua kemungkinan, banyak yang kosong.

Di NoSQL (contoh: MongoDB), setiap data disimpan seperti dokumen yang bisa berbeda-beda bentuknya:

// Pengguna A
{ "nama": "Budi", "telepon": "0812xxx", "alamat": "Jakarta" }

// Pengguna B  
{ "nama": "Sari", "hobi": ["membaca", "memasak"] }

Cocok untuk: data yang bentuknya tidak seragam, data yang sangat banyak dan perlu disimpan cepat (media sosial, analitik, konten aplikasi).

Perbedaan utama yang perlu diingat

Indexing — Kenapa pencarian bisa cepat?

Bayangkan kamu ingin mencari nama “Sutrisno” di buku telepon setebal 1000 halaman. Kalau tidak ada urutan abjad, kamu harus baca satu per satu dari halaman pertama.

Index di database bekerja persis seperti urutan abjad di buku telepon — ia membuat pencarian menjadi sangat cepat, tanpa harus memeriksa setiap baris data.

Tapi ada harganya (ingat trade-off!): setiap kali ada data baru yang masuk, index harus diperbarui. Jadi operasi penulisan data menjadi sedikit lebih lambat.

Bab 1.7 — Security: Siapa yang Boleh Masuk?

Dua konsep dasar

Authentication (Autentikasi) — Membuktikan siapa kamu.

Ini seperti menunjukkan KTP di pintu masuk gedung. Sistemnya bertanya: “Siapa kamu?” Kamu menjawab dengan username dan password, dan sistem memverifikasi apakah itu benar.

Authorization (Otorisasi) — Setelah terbukti siapa kamu, apa yang boleh kamu lakukan?

Ini seperti kartu akses gedung. Walaupun kamu sudah masuk, kartu karyawan biasa tidak bisa membuka ruang server. Hanya IT admin yang bisa.

Keduanya berbeda:

• Authentication: “Apakah ini benar-benar Budi?”
• Authorization: “Apakah Budi boleh mengakses halaman admin?”

Least Privilege — Berikan akses seminimal mungkin

Prinsip ini sederhana: setiap orang atau sistem hanya boleh punya akses ke hal-hal yang memang dibutuhkannya, tidak lebih.

Karyawan gudang tidak perlu punya akses ke data gaji. Aplikasi yang hanya butuh membaca data tidak perlu diberi akses untuk menghapus data.

Kenapa ini penting? Karena kalau terjadi kebocoran (akun diretas, data dicuri), kerusakannya terbatas. Peretas yang berhasil masuk lewat akun gudang tidak bisa langsung mengakses data keuangan.

Enkripsi — Data yang tidak bisa dibaca orang lain

Bayangkan kamu mengirim surat cinta lewat pos. Siapapun yang membuka amplop bisa membacanya.

Enkripsi adalah seperti menulis surat dalam bahasa sandi yang hanya kamu dan penerima yang tahu kuncinya. Walaupun ada orang yang mencuri suratnya di tengah jalan, mereka hanya akan melihat kalimat acak yang tidak bermakna.

Ini yang terjadi setiap kali kamu melihat https:// di browser — datamu dienkripsi selama pengiriman.

Bab 1.8 — Observability: Bagaimana Kamu Tahu Sistemmu Sehat?

Masalah yang sering diabaikan pemula

Banyak programmer yang sibuk membangun sistem, tapi tidak pernah berpikir: “Bagaimana aku tahu kalau sistem ini bermasalah?”

Analoginya: kamu membangun mobil yang canggih, tapi tidak memasang speedometer, indikator bensin, atau lampu peringatan mesin. Kamu tidak akan tahu ada masalah sampai mobil berhenti di tengah jalan.

Tiga pilar observability

Logging — Catatan kejadian

Log adalah catatan otomatis yang ditulis sistem setiap kali sesuatu terjadi. Seperti buku harian sistem.

[2024-03-15 08:32:11] INFO  Pengguna 'budi@email.com' berhasil login
[2024-03-15 08:33:05] INFO  Pesanan #1234 berhasil dibuat
[2024-03-15 08:33:06] ERROR Gagal mengirim email konfirmasi ke budi@email.com
[2024-03-15 08:40:22] WARN  Koneksi database lambat: 3.2 detik

Ketika ada laporan “saya tidak terima email konfirmasi”, kamu bisa buka log dan langsung tahu: ah, ada error di bagian pengiriman email.

Monitoring — Pemantauan kondisi sistem secara real-time

Monitoring adalah seperti papan instrumen pesawat — menampilkan berbagai angka penting secara terus-menerus: berapa persen CPU terpakai, berapa banyak memori tersisa, berapa banyak request per detik yang masuk.

Dan kalau ada angka yang melampaui batas (misalnya CPU mencapai 95%), sistem akan mengirim alert — alarm otomatis — sehingga tim teknismu bisa bertindak sebelum sistem benar-benar crash.

Tracing — Melacak perjalanan satu request

Bayangkan pengguna mengeluh: “Kenapa checkout saya lambat, butuh 8 detik?”

Dengan tracing, kamu bisa lihat perjalanan lengkap request itu: ternyata 7 detik dihabiskan menunggu response dari sistem pembayaran pihak ketiga, bukan dari sistemmu sendiri.

Tanpa tracing, kamu hanya bisa menebak-nebak di mana bottleneck-nya.

Bagian 2: Domain Spesifik

Setelah fondasi kuat, saatnya mempelajari arsitektur di area-area spesifik.

Bab 2.1 — Arsitektur Web

Bagaimana sebuah website bekerja dari ujung ke ujung?

Ketika kamu mengetik tokopedia.com dan menekan Enter, banyak hal terjadi dalam hitungan milidetik. Mari kita ikuti perjalanannya.

Langkah 1: DNS Lookup Browsermu bertanya ke DNS: “Di mana alamat IP tokopedia.com?” DNS menjawab dengan alamat IP server Tokopedia.

Langkah 2: Request tiba di Load Balancer Tokopedia bukan hanya satu server. Ada ribuan server. Load balancer adalah “petugas antrian” yang memutuskan: request ini dikirim ke server mana supaya beban terbagi merata.

Langkah 3: Server memproses request Server yang dipilih menjalankan kode, mengambil data dari database, dan menyiapkan halaman yang akan ditampilkan.

Langkah 4: Database query Kalau kamu mencari “sepatu Nike”, server meminta ke database: “Berikan saya semua produk dengan kata kunci ‘sepatu Nike’.” Database mencari dan mengirim hasilnya.

Langkah 5: Cache (mungkin) Kalau pencarian “sepatu Nike” sangat populer, hasil pencariannya mungkin sudah disimpan di cache (memori cepat). Daripada tanya database lagi, server langsung ambil dari cache — jauh lebih cepat.

Langkah 6: CDN Gambar-gambar produknya tidak diambil dari server utama. Mereka disimpan di CDN (Content Delivery Network) — jaringan server yang tersebar di seluruh dunia. Kamu di Surabaya, gambarnya diambil dari server CDN yang paling dekat denganmu, bukan dari Jakarta atau Singapura.

Langkah 7: Response dikirim ke browsermu Semua ini terjadi dalam waktu kurang dari 1 detik.

Monolith vs Microservices — Dua pendekatan besar

Arsitektur Monolith

Seluruh aplikasi dibangun sebagai satu kesatuan besar. Fitur login, katalog produk, keranjang belanja, pembayaran, notifikasi — semua ada dalam satu “gumpalan” kode.

[Satu Aplikasi Besar]
├── Modul Login
├── Modul Katalog
├── Modul Keranjang
├── Modul Pembayaran
└── Modul Notifikasi

Keuntungan monolith:

• Mudah di-develop di awal
• Mudah di-debug (semuanya ada di satu tempat)
• Lebih mudah di-deploy
• Cocok untuk tim kecil dan startup yang masih bereksperimen

Kekurangan monolith:

• Kalau satu bagian crash (misalnya modul notifikasi), seluruh aplikasi bisa terpengaruh
• Sulit untuk di-scale hanya bagian tertentu saja
• Semakin besar, semakin lambat proses development dan deploy

Arsitektur Microservices

Aplikasi dipecah menjadi banyak “layanan kecil” yang masing-masing berdiri sendiri dan punya database sendiri.

[Layanan Login]     ←→  [Database Pengguna]
[Layanan Katalog]   ←→  [Database Produk]
[Layanan Keranjang] ←→  [Database Keranjang]
[Layanan Pembayaran]←→  [Database Transaksi]
[Layanan Notifikasi]←→  [Queue Email/SMS]

Setiap layanan bisa di-develop, di-deploy, dan di-scale secara independen.

Keuntungan microservices:

• Kalau layanan notifikasi down, layanan pembayaran tetap jalan
• Bisa scale hanya layanan yang butuh (misalnya saat promo, layanan katalog di-scale, layanan login tidak perlu)
• Tim yang berbeda bisa mengerjakan layanan yang berbeda secara bersamaan

Kekurangan microservices:

• Jauh lebih kompleks untuk di-setup dan di-maintain
• Debugging lebih sulit (masalah bisa ada di layanan mana dari sekian banyak layanan)
• Butuh tim dan infrastruktur yang lebih matang
• Jangan pakai microservices kalau kamu masih startup kecil — kamu akan mati kelelahan mengurus kompleksitasnya sebelum produkmu sempat berkembang

Aturan praktis: Mulai dengan monolith. Pindah ke microservices hanya ketika kamu sudah tahu persis bagian mana yang perlu di-scale secara terpisah, dan timmu sudah cukup besar dan matang.

Caching — Simpan hasil kerja yang sudah dilakukan

Bayangkan kamu ditanya: “Berapa 7 kali 8?” Kamu berpikir sebentar: 56.

Lalu lima menit kemudian orang lain tanya hal yang sama. Kamu tidak perlu berpikir lagi — kamu sudah tahu jawabannya 56.

Cache bekerja persis seperti itu. Hasil dari operasi yang mahal (query database besar, kalkulasi kompleks, panggilan ke API eksternal) disimpan sementara. Kalau ada yang tanya hal yang sama, langsung jawab dari cache tanpa perlu mengulang pekerjaan.

Yang perlu diperhatikan: data di cache bisa “basi” (outdated). Kamu harus memutuskan: berapa lama cache ini valid sebelum perlu diperbarui? Ini adalah trade-off antara kecepatan dan keakuratan data.

Bab 2.2 — Arsitektur Mobile

Mobile bukan web yang dikecilkan

Banyak developer web yang mencoba membuat aplikasi mobile dengan pendekatan yang sama seperti web. Hasilnya biasanya mengecewakan — aplikasi boros baterai, lambat, atau tidak nyaman digunakan.

Mobile punya karakteristik unik yang harus mempengaruhi cara kamu merancang arsitekturnya:

• Koneksi internet bisa tidak stabil atau tidak ada sama sekali
• Memori terbatas
• Baterai terbatas — setiap operasi ada “harganya” dalam milliampere
• Pengguna berinteraksi dengan sentuhan, bukan mouse
• Sistem operasi bisa membunuh aplikasimu kapan saja kalau memori menipis

Offline-first — Rancang untuk kondisi terburuk

Offline-first adalah pendekatan di mana kamu merancang aplikasimu untuk bekerja dengan baik bahkan tanpa koneksi internet, dan sinkronisasi dengan server terjadi di background ketika koneksi tersedia.

Contoh nyata: Google Maps bisa kamu gunakan di dalam terowongan tanpa sinyal (untuk rute yang sudah diunduh). Catatan di Notion tetap bisa diedit walau internet mati, dan akan tersinkronisasi otomatis ketika online kembali.

Ini butuh strategi khusus:

• Local storage: Data disimpan di perangkat pengguna
• Conflict resolution: Bagaimana kalau pengguna edit di HP dan di laptop saat offline, lalu keduanya sinkronisasi? Data mana yang “menang”?
• Background sync: Sinkronisasi berjalan diam-diam di belakang layar

Native vs Cross-platform

Native — membangun aplikasi khusus untuk satu platform.

Aplikasi iOS ditulis dengan Swift, aplikasi Android ditulis dengan Kotlin. Dua kode yang berbeda, dua tim yang berbeda, dua kali pekerjaan.

• ✅ Performa terbaik, akses penuh ke fitur perangkat
• ✅ Tampilan dan perilaku sesuai standar platform
• ❌ Biaya dua kali lipat untuk support dua platform

Cross-platform — satu kode untuk banyak platform.

Framework seperti Flutter (dari Google) atau React Native (dari Meta) memungkinkan kamu menulis satu kode dan menghasilkan aplikasi untuk iOS sekaligus Android.

• ✅ Hemat biaya dan waktu
• ✅ Satu tim, satu codebase
• ❌ Performa sedikit di bawah native untuk kasus tertentu
• ❌ Terkadang ada fitur platform yang belum didukung

Aturan praktis untuk bisnis: Kalau budget terbatas dan produkmu perlu ada di iOS dan Android, pilih cross-platform. Kalau aplikasimu butuh performa sangat tinggi (game, kamera, augmented reality) atau kamu punya budget lebih, native mungkin lebih tepat.

State Management — Mengelola “kondisi” aplikasi

State adalah kondisi aplikasi pada satu momen tertentu. Contoh: pengguna sudah login atau belum, isi keranjang belanja, apakah loading sedang berlangsung, halaman mana yang sedang dibuka.

Ini kedengarannya sepele, tapi dalam aplikasi yang kompleks dengan banyak layar dan interaksi, mengelola state bisa menjadi sangat rumit.

Bayangkan pengguna menambahkan produk ke keranjang di Layar Produk. Bagaimana Layar Keranjang tahu ada produk baru? Bagaimana ikon keranjang di navigation bar tahu untuk update jumlah produknya?

Ada banyak pendekatan (Redux, BLoC, Provider, Riverpod, dll.) tapi intinya semua sama: ada satu sumber kebenaran tunggal tentang kondisi aplikasi, dan semua komponen merespons perubahan state tersebut.

Bab 2.3 — Arsitektur Desktop

Karakteristik yang berbeda dari web dan mobile

Aplikasi desktop (seperti VS Code, Photoshop, Microsoft Word) punya karakteristik unik:

• Biasanya terhubung langsung ke sistem operasi
• Bisa akses file di komputer pengguna
• Sering berjalan tanpa koneksi internet
• Pengguna berinteraksi dengan keyboard dan mouse — interaksi yang lebih presisi dan kompleks
• Sering butuh performa tinggi (video editing, rendering 3D, kompilasi kode)

Electron vs Native — Trade-off besar di desktop

Electron adalah framework yang memungkinkan kamu membangun aplikasi desktop menggunakan teknologi web (HTML, CSS, JavaScript). VS Code, Slack, Discord, Figma — semua dibangun dengan Electron.

• ✅ Developer web langsung bisa membuat aplikasi desktop
• ✅ Satu kode untuk Windows, Mac, Linux
• ❌ Boros memori (setiap aplikasi Electron membawa browser mini di dalamnya)
• ❌ Ukuran file instalasi besar
• ❌ Tidak se-smooth aplikasi native

Tauri adalah alternatif Electron yang lebih ringan — menggunakan WebView bawaan sistem operasi, bukan browser penuh.

Native desktop:

• Windows: menggunakan WinUI (C#/XAML)
• macOS: menggunakan SwiftUI (Swift)
• Linux: menggunakan GTK atau Qt (C++/Python)

IPC — Ketika bagian-bagian aplikasi perlu berbicara

Aplikasi desktop yang kompleks sering terdiri dari beberapa proses yang berjalan bersamaan. Misalnya di VS Code: ada proses utama (UI), ada proses extension host (menjalankan plugins), ada proses language server (menganalisis kode).

IPC (Inter-Process Communication) adalah mekanisme agar proses-proses ini bisa saling berkomunikasi dengan aman tanpa saling mengganggu.

Bayangkan seperti berbagai divisi di kantor yang berbagi informasi lewat sistem memo internal — setiap divisi bekerja sendiri, tapi bisa berkoordinasi.

Bab 2.4 — Arsitektur Sistem Operasi

Mengapa ini penting untuk programmer?

Kamu tidak perlu membangun sistem operasi sendiri. Tapi memahami cara kerja OS membuat kamu bisa:

• Menulis program yang lebih efisien
• Mendiagnosis masalah performa
• Memahami kenapa program kadang “crash” atau “hang”
• Membuat pilihan arsitektur yang lebih tepat

Process vs Thread — Dua cara menjalankan kode bersamaan

Process adalah program yang sedang berjalan. Setiap aplikasi yang kamu buka adalah sebuah process. Setiap process punya “ruang pribadi” sendiri di memori — process satu tidak bisa langsung mengakses memori process lain.

Thread adalah “anak tugas” di dalam sebuah process. Satu process bisa punya banyak thread yang bekerja bersamaan, dan semua thread dalam satu process berbagi memori yang sama.

Analogi: bayangkan sebuah restoran.

• Process = restoran (punya dapur sendiri, meja sendiri, tidak bisa pakai dapur restoran sebelah)
• Thread = pelayan di dalam restoran itu (semuanya berbagi dapur yang sama, bisa bekerja bersamaan)

Keuntungan thread: cepat untuk berkomunikasi karena berbagi memori. Bahaya thread: karena berbagi memori, dua thread bisa “bertabrakan” saat mengakses data yang sama secara bersamaan. Ini disebut race condition — salah satu bug yang paling susah ditemukan dan diperbaiki.

Memory Management — Siapa yang mengatur memori?

Setiap program butuh memori untuk bekerja. OS yang mengatur siapa dapat memori berapa, dan memastikan satu program tidak “mencuri” memori program lain.

Stack — Memori untuk hal-hal sementara. Ketika sebuah fungsi dipanggil, OS menyiapkan “ruang kerja” di stack untuk variabel-variabel fungsi itu. Ketika fungsi selesai, ruang itu langsung dikembalikan. Sangat cepat, tapi terbatas ukurannya.

Heap — Memori untuk hal-hal yang perlu bertahan lebih lama. Ketika kamu membuat objek besar yang perlu ada selama aplikasi berjalan, itu disimpan di heap. Lebih fleksibel, tapi ada tanggung jawab: memori yang sudah tidak dipakai harus dikembalikan, kalau tidak akan terjadi memory leak — aplikasimu pelan-pelan makan memori terus sampai akhirnya crash.

Bahasa seperti Java dan Python punya Garbage Collector — program otomatis yang mencari dan membersihkan memori yang sudah tidak dipakai. Bahasa seperti C dan C++ tidak punya, jadi programmer harus mengaturnya sendiri.

Virtual Memory — Ilusi memori tak terbatas

Komputer kamu mungkin punya RAM 8GB. Tapi kamu bisa membuka banyak aplikasi sekaligus yang kalau dijumlah, memorinya jauh melebihi 8GB. Bagaimana bisa?

OS menggunakan teknik virtual memory: bagian memori yang sedang tidak aktif digunakan dipindahkan sementara ke harddisk (disebut swap). Ketika dibutuhkan lagi, dikembalikan ke RAM. Ini memberikan ilusi bahwa RAM-mu jauh lebih besar dari kenyataannya.

Kelemahannya: mengakses data dari harddisk jauh lebih lambat daripada dari RAM. Kalau komputer kamu sering “lemot” saat banyak program terbuka, bisa jadi OS sedang banyak melakukan swap.

Bab 2.5 — Arsitektur Sistem AI

Ini bukan tentang cara kerja AI-nya, tapi cara merancang sistem yang menggunakan AI

Bayangkan kamu diminta membangun aplikasi chatbot layanan pelanggan menggunakan AI. Bukan hanya “sambungkan ke API OpenAI dan selesai.” Ada banyak pertimbangan arsitektur yang perlu kamu pikirkan.

Pipeline ML — Perjalanan dari data mentah ke model yang berguna

Sebelum model AI bisa digunakan, ada proses panjang yang disebut ML Pipeline:

Data Mentah → Pembersihan Data → Feature Engineering → Training Model → Evaluasi → Deployment → Monitoring

Data Mentah: Data asli yang belum diproses. Bisa berupa teks, gambar, angka, rekaman suara. Biasanya “kotor” — ada yang hilang, ada yang salah format, ada yang duplikat.

Pembersihan Data: Proses membuang data yang rusak, mengisi data yang hilang, menyeragamkan format. Sering disebut “80% pekerjaan data scientist adalah membersihkan data.”

Feature Engineering: Memilih dan mengubah data mentah menjadi bentuk yang bisa dipahami model. Misalnya, mengubah tanggal menjadi “hari dalam seminggu” atau “bulan ke-berapa dalam tahun”.

Training: Melatih model menggunakan data yang sudah bersih. Proses ini bisa membutuhkan waktu jam, hari, bahkan minggu tergantung ukuran data dan model.

Evaluasi: Mengetes model dengan data yang belum pernah dilihat sebelumnya. Apakah akurasinya cukup? Apakah ada bias?

Deployment: Mempublikasikan model agar bisa diakses oleh aplikasi. Model yang “hidup” di server dan siap menjawab pertanyaan disebut inference server.

Monitoring: Setelah model berjalan di produksi, kamu harus terus memantaunya. Data di dunia nyata terus berubah — tren bahasa berubah, perilaku pengguna berubah. Model yang bagus hari ini bisa menjadi tidak akurat setelah 6 bulan. Ini disebut model drift.

RAG — Cara membuat AI “tahu” tentang data milikmu

LLM seperti ChatGPT dilatih dengan data yang memiliki tanggal kadaluarsa. Ia tidak tahu tentang produk baru perusahaanmu, kebijakan terbaru, atau dokumen internal yang tidak pernah dipublikasikan ke internet.

RAG (Retrieval-Augmented Generation) adalah solusinya:

1. Dokumen-dokumen internalmu (PDF, artikel, manual produk) dipecah jadi potongan-potongan kecil
2. Setiap potongan diubah menjadi embedding — representasi numerik dari makna teks itu
3. Semua embedding disimpan di vector database (database khusus untuk menyimpan embedding)
4. Ketika pengguna bertanya, pertanyaannya juga diubah jadi embedding
5. Sistem mencari embedding yang paling “mirip” dengan pertanyaan di vector database
6. Potongan dokumen yang relevan itu dikirimkan ke LLM sebagai konteks tambahan
7. LLM menjawab berdasarkan dokumen tersebut

Hasilnya: AI yang bisa menjawab pertanyaan tentang data spesifik milikmu, bukan hanya pengetahuan umum.

Agentic System — AI yang bisa bertindak

LLM biasa hanya menjawab pertanyaan. AI Agent bisa melakukan tindakan.

Contoh: daripada hanya menjawab “untuk memesan tiket, kamu bisa buka website ini…”, sebuah AI agent bisa langsung membuka website itu, mengisi formulir, dan melakukan pemesanan atas namamu.

Cara kerja dasarnya:

Perintah Pengguna
      ↓
AI Berpikir: "Apa yang harus kulakukan pertama?"
      ↓
Ambil Tindakan (panggil API, cari di web, baca file, dll.)
      ↓
Observasi: "Apa hasilnya?"
      ↓
AI Berpikir: "Apakah sudah selesai? Kalau belum, langkah selanjutnya?"
      ↓
[Ulangi sampai tugas selesai]
      ↓
Laporkan hasil ke pengguna

Tantangan arsitektur di sini: bagaimana kamu memastikan agent tidak melakukan tindakan yang berbahaya? Bagaimana kamu memastikan agent bisa “ingat” apa yang sudah dilakukan dalam sesi yang panjang? Bagaimana kalau satu tindakan gagal di tengah jalan?

Bab 2.6 — Distributed Systems: Ketika Satu Server Tidak Cukup

Mengapa ini topik tersendiri?

Ketika sistemmu tumbuh besar, satu server tidak lagi cukup. Kamu butuh banyak server yang bekerja bersama. Tapi “banyak server yang bekerja bersama” jauh lebih rumit dari kedengarannya.

CAP Theorem — Batas fisik yang tidak bisa dilanggar

Ini adalah hukum alam di dunia distributed systems. Dikemukakan oleh Eric Brewer, CAP Theorem menyatakan:

Dalam sebuah distributed system, kamu hanya bisa menjamin dua dari tiga hal berikut:

C — Consistency (Konsistensi): Setiap pengguna di manapun selalu melihat data yang sama persis pada saat yang sama.

A — Availability (Ketersediaan): Sistem selalu bisa merespons, tidak pernah error karena tidak tersedia.

P — Partition Tolerance (Toleransi Partisi): Sistem tetap berjalan meskipun ada kegagalan jaringan yang memutus komunikasi antar server.

Kenyataan pahit: P (Partition Tolerance) hampir tidak bisa dihindari di dunia nyata. Jaringan selalu bisa terputus sewaktu-waktu. Jadi pilihan sesungguhnya hanya antara CP (Konsisten tapi mungkin tidak available saat partisi) atau AP (Selalu available tapi data mungkin tidak konsisten saat partisi).

Contoh nyata:

Sistem transfer bank memilih CP: daripada memproses transaksi dengan data yang mungkin tidak akurat, sistem lebih baik menolak transaksi saat ada masalah jaringan. Uang adalah urusan serius — konsistensi adalah prioritas.

Media sosial memilih AP: daripada menampilkan error, lebih baik tampilkan data yang mungkin sedikit ketinggalan (misalnya jumlah like yang belum ter-update). Pengguna lebih terima data “sedikit basi” daripada error.

Eventual Consistency — Tidak harus selalu sama sekarang, tapi akan sama akhirnya

Kalau kamu mengirim pesan WhatsApp ke seseorang, dan dia menerimanya 2 detik kemudian — apakah itu masalah? Tidak, karena pesannya tetap sampai.

Eventual Consistency berarti: data belum tentu sama persis di semua server pada saat yang sama, tapi pada akhirnya (given enough time tanpa update baru) semua server akan punya data yang sama.

Ini cukup untuk banyak kasus. Tidak semua hal butuh konsistensi sempurna seperti sistem bank.

Saga Pattern — Transaksi yang melibatkan banyak layanan

Di sistem monolith, kalau kamu transfer uang, semuanya terjadi dalam satu transaksi database: kurangi saldo pengirim, tambah saldo penerima. Kalau salah satu gagal, semua dibatalkan.

Di microservices, saldo pengirim ada di database Layanan Akun A, saldo penerima ada di database Layanan Akun B. Kamu tidak bisa punya satu transaksi yang menjangkau dua database berbeda.

Saga Pattern adalah solusinya: pecah transaksi besar menjadi serangkaian transaksi kecil yang masing-masing bisa di-rollback.

1. Kurangi saldo pengirim → Berhasil
2. Tambah saldo penerima → GAGAL
3. Kompensasi: Kembalikan saldo pengirim → Berhasil

Setiap langkah punya “langkah kompensasi” yang siap dijalankan kalau langkah selanjutnya gagal.

Bagian 3: Capaian Kompetensi yang Harus Kamu Jadikan Acuan

Ini adalah daftar kemampuan konkret yang harus kamu miliki. Bukan teori — ini kemampuan nyata yang bisa diuji.

Level 1: Dasar (Target: 3–6 bulan belajar aktif)

Kamu bisa dikatakan mencapai level ini kalau kamu bisa melakukan hal-hal berikut tanpa membuka catatan:

Pemahaman Konsep

• Kamu bisa menjelaskan apa itu sistem, dan menyebutkan input, proses, output dari sebuah aplikasi yang kamu kenal
• Kamu bisa menjelaskan apa itu trade-off dengan contoh yang kamu buat sendiri (bukan contoh dari tutorial)
• Kamu bisa menjelaskan perbedaan authentication dan authorization dalam satu menit
• Kamu bisa menjelaskan kenapa caching ada, dan apa risikonya
• Kamu bisa menjelaskan perbedaan SQL dan NoSQL dan kapan pakai masing-masing

Kemampuan Praktis

• Kamu bisa menggambar (di kertas atau whiteboard) arsitektur sederhana sebuah aplikasi: pengguna → frontend → backend → database
• Kamu bisa membaca sebuah diagram arsitektur yang sudah ada dan menjelaskan cara kerjanya
• Kamu bisa mengidentifikasi “single point of failure” dalam sebuah sistem sederhana (bagian mana yang kalau mati, seluruh sistem ikut mati)
• Kamu bisa menjelaskan perbedaan monolith dan microservices, dan kapan masing-masing tepat digunakan

Tes Mandiri

Ambil sebuah aplikasi yang kamu gunakan sehari-hari (misalnya GoJek). Gambar arsitekturnya di kertas — tidak perlu sempurna, tidak perlu detail. Tunjukkan aliran data dari pengguna memesan, sampai driver menerima notifikasi. Kalau kamu bisa melakukan ini dan menjelaskannya ke orang lain, kamu sudah di level dasar.

Level 2: Menengah (Target: 6–12 bulan setelah Level 1)

Pemahaman Konsep

• Kamu bisa menjelaskan CAP Theorem dengan contoh nyata
• Kamu bisa menjelaskan perbedaan process dan thread, dan kapan pakai masing-masing
• Kamu bisa menjelaskan cara kerja RAG dari awal sampai akhir
• Kamu bisa menjelaskan apa itu eventual consistency dan mengapa diperlukan

Kemampuan Praktis

• Kamu bisa merancang arsitektur sistem dari nol untuk soal sederhana seperti: “Rancang sistem URL shortener (seperti bit.ly)”
• Selama merancang, kamu secara aktif menyebut trade-off dari setiap pilihan yang kamu buat
• Kamu bisa mengestimasi skala sistem: “Kalau ada 1 juta pengguna per hari, kira-kira berapa server yang dibutuhkan?”
• Kamu bisa membaca log aplikasi dan mengidentifikasi di mana masalah terjadi
• Kamu bisa merancang strategi caching untuk skenario spesifik

Tes Mandiri

Cari soal sistem design interview di Google (misalnya: “Design Twitter”, “Design Netflix”, “Design WhatsApp”). Coba jawab sendiri di kertas dalam 45 menit. Rekam dirimu menjelaskannya. Dengarkan kembali. Apakah penjelasanmu masuk akal? Apakah kamu menyebut trade-off? Apakah kamu mempertimbangkan skalabilitas?

Level 3: Mahir (Target: 1–2 tahun setelah Level 2)

Pemahaman Konsep

• Kamu bisa menjelaskan Saga Pattern dan kapan menggunakannya vs 2-Phase Commit
• Kamu bisa menjelaskan cara kerja consensus algorithm (Raft/Paxos) secara konseptual
• Kamu bisa menjelaskan berbagai strategi sharding database dan trade-off masing-masing
• Kamu bisa merancang sistem monitoring lengkap untuk sebuah aplikasi produksi

Kemampuan Praktis

• Kamu bisa melakukan code review dari perspektif arsitektur: mengidentifikasi bottleneck, potensi masalah skalabilitas, risiko keamanan
• Kamu bisa memberikan rekomendasi arsitektur yang berbeda untuk context yang berbeda (bukan satu jawaban yang dianggap selalu benar)
• Kamu bisa mengestimasi biaya infrastruktur dari sebuah desain arsitektur
• Kamu bisa melakukan capacity planning: berapa storage yang dibutuhkan dalam 1 tahun, berapa bandwidth yang perlu disiapkan

Tes Mandiri

Ambil sistem yang kamu kerjakan saat ini di pekerjaanmu. Buat dokumentasi arsitekturnya lengkap: apa komponen-komponennya, bagaimana mereka berkomunikasi, apa trade-off dari desain yang dipilih, apa risikonya, apa yang perlu diperbaiki. Kalau kamu bisa membuat dokumen ini dan membela setiap keputusan di dalamnya, kamu sudah di level mahir.

Bagian 4: Panduan Belajar dan Sumber Referensi

Urutan Belajar yang Benar

Bulan 1–2: Bangun fondasi dulu Jangan terburu-buru masuk ke domain spesifik. Habiskan waktu memahami Bab 1 dengan benar. Baca, pikirkan, cari contoh nyata dari hidupmu sehari-hari untuk setiap konsep.

Bulan 3–4: Pilih satu domain, dalami Pilih domain yang paling relevan dengan pekerjaanmu sekarang. Kalau kamu web developer, mulai dari Bab 2.1. Dalami sampai kamu bisa mengerjakan soal-soal system design level dasar dengan nyaman.

Bulan 5–6: Praktik dengan soal nyata Cari soal-soal system design interview dan coba jawab. Ini adalah cara terbaik untuk menguji apakah kamu benar-benar paham atau hanya “tahu teorinya”.

Bulan 7–12: Perluas ke domain lain dan distributed systems Setelah satu domain kuat, pelajari domain lain. Dan mulailah mempelajari distributed systems — ini yang mengikat semua domain bersama.

Setelah 1 tahun: Kontribusi dan ajarkan Cara terbaik untuk memastikan kamu benar-benar paham adalah dengan mengajarkannya ke orang lain. Tulis artikel, buat presentasi, review arsitektur teman.

Buku yang Wajib Dibaca (Urutan Prioritas)

Untuk semua orang, baca ini dulu:

1. “Designing Data-Intensive Applications” — Martin Kleppmann
   Buku terbaik untuk memahami arsitektur sistem modern. Tidak butuh background khusus untuk membacanya, tapi butuh kesabaran.

Untuk yang fokus ke AI systems: 2. “Designing Machine Learning Systems” — Chip Huyen
Cara merancang sistem ML yang bisa digunakan di produksi nyata, bukan hanya di notebook.

Untuk yang ingin memahami OS lebih dalam: 3. “Operating Systems: Three Easy Pieces” — Arpaci-Dusseau (tersedia gratis online)
Buku OS terbaik yang pernah ada, dan gratis.

Untuk yang sudah di level menengah: 4. “System Design Interview” — Alex Xu (Volume 1 dan 2)
Panduan praktis untuk menjawab soal system design.

Referensi Online Gratis

• ByteByteGo (YouTube & Newsletter) — Penjelasan arsitektur sistem dalam bentuk visual yang mudah dipahami
• System Design Primer (GitHub: donnemartin/system-design-primer) — Kompilasi lengkap materi system design, gratis
• Martin Fowler’s Blog (martinfowler.com) — Tulisan mendalam tentang berbagai pola arsitektur
• High Scalability Blog (highscalability.com) — Studi kasus arsitektur perusahaan besar (Netflix, Airbnb, Uber, dll.)

Cara Belajar yang Efektif

Jangan hanya membaca — gambarlah.
Setiap kali kamu belajar konsep baru, gambar diagram-nya. Tangan yang bergerak membantu otak mengingat.

Cari analogi sendiri.
Setiap konsep teknis punya padanannya di kehidupan nyata. Kalau kamu bisa menemukan analoginya, berarti kamu sudah benar-benar mengerti.

Ajarkan ke orang lain.
Ini bukan klise. Ketika kamu mencoba menjelaskan sesuatu ke orang lain, kamu akan menemukan lubang-lubang dalam pemahamanmu sendiri.

Baca studi kasus nyata.
Bagaimana Netflix merancang sistem rekomendasinya? Bagaimana WhatsApp bisa menangani miliaran pesan per hari dengan tim yang sangat kecil? Jawaban atas pertanyaan-pertanyaan ini adalah pelajaran arsitektur yang tidak ternilai. Cari di blog teknis perusahaan-perusahaan besar.

Bersabarlah dengan dirimu sendiri.
Architectural thinking bukan sesuatu yang bisa dikuasai dalam sebulan. Ini adalah cara berpikir yang terbentuk dari waktu ke waktu, dari pengalaman, dari kesalahan, dan dari diskusi dengan orang lain. Setiap hari yang kamu habiskan belajar ini adalah investasi jangka panjang.

Terakhir diperbarui: Mei 2026
Dokumen ini adalah kurikulum hidup — terus diperbarui seiring perkembangan industri.