3.0 Pengantar Bagian 3: Sistem
Arsitektur adalah himpunan keputusan yang mahal untuk dibalik. Bagaimana Anda membagi sistem menjadi bagian-bagian? Bagaimana bagian-bagian itu berbicara satu sama lain? Bagaimana data dimodelkan? Dan bagaimana keseluruhannya berperilaku di bawah beban dan di bawah kegagalan? Bagian 3 membahas pengambilan keputusan itu dengan sengaja. Pada tim kecil, arsitektur dapat hidup di beberapa kepala dan berkembang seiring jalan. Dalam organisasi besar (ratusan insinyur, puluhan tim, sistem yang akan hidup lebih lama daripada karier orang yang membangunnya), arsitektur menjadi hal yang menjaga semua orang tetap terkoordinasi. Ketika jelas, tim bergerak secara independen tanpa bertabrakan. Ketika kabur, setiap dependensi lintas tim berubah menjadi negosiasi, dan setiap insiden berubah menjadi proyek arkeologi.
Taruhannya tertinggi di enterprise dan pemerintah. Mesin pajak, platform tunjangan, rekam medis nasional, atau buku besar inti bank berumur panjang, sangat diatur, dibagikan lintas departemen, dan bertanggung jawab kepada publik. Keputusan yang Anda buat hari ini tentang kopling, kepemilikan data, dan atribut kualitas akan membatasi apa yang mungkin selama satu dekade atau lebih. Regulator dan auditor makin mengharapkan arsitektur yang terdokumentasi dan dapat dipertanggungjawabkan, dengan bukti nyata bahwa keandalan, keamanan, privasi, dan ketahanan dirancang masuk, bukan ditempelkan belakangan. Kegagalan yang menjadi berita utama adalah kegagalan arsitektural: portal yang ambruk pada hari peluncuran, sistem pengajuan yang timeout pada tenggat, migrasi yang kehilangan atau menghitung ganda catatan.
Bagian ini dimulai dengan fundamental yang tahan lama, bergerak melalui pilihan struktural yang konkret, lalu ke kenyataan distribusi, data, dan skala, dan diakhiri dengan masalah tersulit yang sebenarnya dihadapi kebanyakan organisasi besar: memodernisasi sistem yang sudah mereka jalankan. Benang yang mengikat semuanya: arsitektur yang baik adalah serangkaian trade-off yang sadar, bukan bawaan yang sedang tren.
Bab dalam bagian ini
3.1 Dasar-dasar arsitektur. Perkakas tahan lama yang bertahan dari mode teknologi: atribut kualitas (si “-ilities”), persyaratan signifikan arsitektural, fitness function (tes otomatis yang menjaga kualitas arsitektural terpilih) dan arsitektur evolusioner, dokumentasi ringan dengan model C4 (diagram arsitektur bersarang pada empat tingkat zoom) dan arc42 (templat dokumentasi arsitektur), serta analisis trade-off terstruktur.
3.2 Gaya dan pola arsitektural. Tinjauan bentuk sistem utama, dari monolit hingga mikroservis, arsitektur berbasis peristiwa dengan CQRS (Command Query Responsibility Segregation, yang memisahkan model baca dari model tulis) dan event sourcing (menyimpan status sebagai log peristiwa append-only), service mesh (lapisan infrastruktur khusus untuk komunikasi layanan-ke-layanan) dan gateway, serverless, serta arsitektur heksagonal dan bersih, dengan panduan kapan masing-masing cocok, dibingkai oleh Hukum Conway (sistem cenderung mencerminkan struktur komunikasi organisasi yang membangunnya).
3.3 Sistem terdistribusi. Kebenaran pahit yang muncul begitu Anda melintasi batas jaringan (jaringan tidak andal, kegagalan parsial, tanpa jam bersama), dan pertahanan baku: penalaran konsistensi, idempotensi (membuat operasi aman diulang), retry dengan backoff, circuit breaker (yang berhenti memanggil dependensi yang gagal), saga (urutan transaksi lokal dengan langkah pembatalan kompensasi), dan observabilitas terdistribusi.
3.4 Arsitektur data dan penyimpanan. Bagaimana data dimodelkan, disimpan, dijaga konsisten, dan disajikan cepat pada skala besar: paradigma penyimpanan utama dan kapan memakai masing-masing, polyglot persistence (memakai beberapa penyimpanan data khusus dalam satu sistem), evolusi skema dan migrasi, caching dan CDN (content delivery network), serta transaksi dan konkurensi di bawah beban.
3.5 Skalabilitas, kinerja, dan ketahanan. Tiga kualitas berbeda yang dirancang masuk alih-alih dipasang belakangan: penskalaan horizontal dan vertikal, tanpa status dan sharding (membagi data lintas mesin menurut kunci), penyeimbangan beban dan autoscaling, anggaran kinerja, pola ketahanan dan chaos engineering, serta pemulihan bencana multiwilayah yang dibingkai oleh RTO (recovery time objective) dan RPO (recovery point objective).
3.6 Modernisasi warisan. Pola bertahap yang benar-benar berhasil, strangler fig (menumbuhkan sistem baru di sekitar yang lama sampai yang lama dapat dipensiunkan) dan branch-by-abstraction (mengganti komponen di balik antarmuka pada jalur utama pengembangan), ditambah penilaian risiko warisan, kepengurusan mainframe dan COBOL (Common Business-Oriented Language), migrasi data dan dual-running, serta cara menahan godaan penulisan ulang besar yang menghasilkan kegagalan termahal di bidang ini.
3.7 Pemeliharaan perangkat lunak. Fase dominan umur perangkat lunak: pemeliharaan korektif, adaptif, perfektif, dan preventif, pemahaman program dan reengineering, serta merancang untuk kemudahan pemeliharaan agar sistem berumur panjang tetap terjangkau untuk diubah.
3.8 Interoperabilitas dan standar terbuka. Merancang sistem untuk berinteroperasi lewat standar terbuka alih-alih integrasi buatan sendiri: interoperabilitas teknis, sintaktis, dan semantik, standar domain seperti FHIR di bidang kesehatan, dan biaya lock-in proprietari.
3.9 Rekayasa sistem. Merekayasa sistem kompleks dari ujung ke ujung, sering menggabungkan perangkat lunak, perangkat keras, manusia, dan proses: siklus hidup, alokasi persyaratan dan keterlacakan, antarmuka, integrasi, serta verifikasi dan validasi.
3.10 Sistem tertanam dan waktu nyata. Perangkat lunak untuk perangkat di bawah kendala ketat: perilaku waktu nyata dan determinisme, RTOS atau firmware bare-metal, memori dan daya terbatas, interaksi dengan perangkat keras, serta standar kritis keselamatan.
3.11 Arsitektur cloud. Merancang untuk cloud alih-alih lift-and-shift pusat data: model layanan dan serverless, wilayah dan zona ketersediaan sebagai domain kegagalan, model tanggung jawab bersama, trade-off layanan terkelola dan lock-in, multi-cloud dan hibrida bila layak kompleksitasnya, serta desain yang sadar biaya dan well-architected.
3.12 Arsitektur berbasis peristiwa dan pesan. Membangun sistem yang berkomunikasi dengan menghasilkan dan bereaksi terhadap peristiwa: antrean versus aliran tahan lama, koreografi versus orkestrasi, event sourcing dan CQRS di tempat yang layak, saga untuk transaksi terdistribusi, jaminan pengiriman dan idempotensi, serta pola yang menjaga alur asinkron tetap andal.
3.13 Jaringan dan konektivitas. Jaringan yang sebenarnya dihadapi insinyur aplikasi: DNS, TCP dan evolusi HTTP, terminasi TLS, penyeimbangan beban dan reverse proxy, pengiriman konten dan edge, penemuan layanan dan service mesh, serta timeout, retry, dan circuit breaker yang membuat ketidakandalan jaringan dapat dilalui.
3.14 Multi-tenancy dan arsitektur SaaS. Melayani banyak pelanggan dari satu instans perangkat lunak tanpa membiarkan mereka saling melihat atau saling membuat kelaparan: spektrum isolasi-versus-efisiensi, partisi data, kuota per tenant terhadap tetangga berisik, siklus hidup tenant, dan atribusi biaya.
3.15 Caching dan pengiriman konten. Menukar sedikit kebasian dengan keuntungan besar dalam latensi, beban, dan biaya di seluruh hierarki cache (klien, edge dan CDN, reverse proxy, aplikasi, dan penyimpanan data), sambil memperlakukan invalidasi cache dan perlindungan stampede sebagai desain kelas satu.
3.16 API gateway dan service mesh. Menangani lalu lintas utara-selatan di API gateway (perutean, autentikasi, pembatasan laju, komposisi) dan lalu lintas timur-barat lewat service mesh (mutual TLS, pergeseran lalu lintas, retry, observabilitas), serta memutuskan kapan mesh pantas kompleksitasnya.
3.17 Pencarian dan temu kembali informasi. Memperlakukan pencarian sebagai sistem kelas satu, dari indeks terbalik dan peringkat relevansi hingga pemahaman kueri, faset, dan temu kembali vektor serta hibrida, dengan evaluasi relevansi nyata alih-alih tebakan.
Bagaimana bab-bab ini saling berkaitan
Bab-bab ini saling membangun menurut urutan. Bab 3.1 memberi Anda kosakata (atribut kualitas dan analisis trade-off) yang dipakai setiap bab berikutnya; si “-ilities” yang dinamainya persis yang dibuat konkret oleh bab 3.4 dan 3.5. Bab 3.2 mengubah fundamental itu menjadi pilihan struktural, dan gaya yang lebih terdistribusi yang didukungnya (mikroservis, berbasis peristiwa, service mesh) membawa biaya yang diajarkan bab 3.3 untuk dikelola. Bab 3.3, 3.4, dan 3.5 bersandar berat satu sama lain: distribusi memaksa keputusan konsistensi dan ketahanan arsitektur data, dan bersama-sama distribusi dan data membentuk skalabilitas dan ketahanan yang sebenarnya dapat Anda capai. Bab 3.6 menutup lingkaran, karena kebanyakan organisasi besar tidak membangun di atas halaman kosong: mereka mengembangkan sistem pencatat yang membatasi setiap pilihan yang dijelaskan bab-bab sebelumnya.
Bagian 3 juga menjangkau ke luar. Bab 3.2 mengambil dari prinsip desain dan Domain-Driven Design bab 2.2 untuk menemukan batas layanan yang baik. Disiplin operasional yang menjaga sistem ini tetap berjalan hidup di Bagian 9: rekayasa keandalan situs (bab 9.1) dan observabilitas (bab 9.2) adalah tempat ketahanan arsitektural dibuktikan di produksi. Sifat keamanan dan privasi yang dituntut regulator dirancang di sini tetapi dirinci di Bagian 4, dan praktik platform serta pengiriman di Bagian 8 menentukan apakah arsitektur benar-benar dapat dirilis dan dioperasikan oleh banyak tim sekaligus.