15 Konsep System Design yang Harus Diketahui Setiap Software Engineer

1. Pengumpulan Requirement

Setiap sistem yang dirancang dengan baik tidak dimulai dengan kode, tetapi dengan pertanyaan. Pengumpulan requirement adalah disiplin ilmu untuk secara sistematis mengidentifikasi dan mengartikulasikan apa yang perlu dilakukan oleh suatu sistem, siapa yang perlu dilayaninya, dan batasan apa yang harus dipatuhinya — sebelum keputusan teknis apa pun dibuat. Ini adalah aktivitas mendasar yang menjadi dasar semua desain sistem selanjutnya, dan merupakan aktivitas yang paling sering dilakukan dengan buruk.

Requirement terbagi dalam dua kategori besar yang harus dipahami oleh setiap engineer, yaitu persyaratan fungsional dan persyaratan non-fungsional. Persyaratan fungsional menjelaskan apa yang dilakukan sistem — fitur, perilaku, dan kasus penggunaan yang harus didukungnya. Aplikasi berbagi tumpangan harus mencocokkan penumpang dengan pengemudi secara real-time, menyediakan navigasi berbasis GPS, memproses pembayaran, dan memelihara riwayat perjalanan. Ini adalah persyaratan fungsional, dan biasanya merupakan titik awal untuk diskusi desain karena paling konkret dan paling langsung terkait dengan kebutuhan pengguna dan bisnis.

Persyaratan non-fungsional menjelaskan bagaimana sistem menjalankan fungsinya, yaitu atribut kualitas yang menentukan apakah sistem tersebut benar-benar dapat digunakan dalam praktik. Berapa banyak pengguna bersamaan yang harus didukung sistem? Berapa waktu respons yang dapat diterima untuk operasi yang paling kritis? Berapa banyak waktu henti yang dapat diterima per tahun? Berapa lama sistem dapat menyimpan data? Persyaratan kepatuhan peraturan apa yang harus dipenuhi? Ini adalah persyaratan non-fungsional, dan seringkali kurang spesifik pada tahap desain awal, yang menyebabkan sistem yang secara teknis melakukan apa yang dirancang untuk dilakukan tetapi gagal melakukannya dengan cara yang berfungsi untuk pengguna nyata pada skala nyata.

2. Arsitektur Sistem

Arsitektur sistem adalah struktur tingkat tinggi dari suatu sistem software — seperti komponen utama, tanggung jawabnya, dan hubungan antar komponen tersebut. Ini adalah cetak biru sebelum pembangunan dimulai, dan seperti cetak biru arsitektur dalam konstruksi, arsitektur sistem yang baik menciptakan kerangka kerja di mana semua keputusan desain dan implementasi selanjutnya dibuat secara konsisten.

Keputusan arsitektur paling mendasar yang dihadapi sebagian besar sistem adalah pilihan antara arsitektur monolitik dan terdistribusi. Monolit menggabungkan semua fungsionalitas aplikasi ke dalam satu unit yang dapat diimplementasikan — satu codebase, satu proses, satu database. Monolit lebih mudah dibangun, diuji, dan diimplementasikan, dan seringkali merupakan pilihan yang tepat untuk produk tahap awal di mana kecepatan iterasi lebih penting daripada skalabilitas horizontal. Monolit menjadi masalah ketika aplikasi berkembang hingga titik di mana satu codebase menjadi sulit dipahami, ketika bagian-bagian sistem yang berbeda memiliki persyaratan penskalaan yang berbeda, atau ketika implementasi perubahan apa pun memerlukan implementasi seluruh aplikasi.

Arsitektur microservices mengatasi keterbatasan ini dengan memecah aplikasi menjadi kumpulan layanan kecil yang dapat diimplementasikan secara independen, masing-masing bertanggung jawab atas domain atau kemampuan tertentu dan berkomunikasi dengan layanan lain melalui antarmuka yang terdefinisi dengan baik — biasanya API REST HTTP atau antrian pesan. Pendekatan microservices memungkinkan setiap layanan untuk diskalakan, diimplementasikan, dan dikembangkan secara independen, dan memungkinkan tim untuk mengerjakan berbagai layanan secara paralel tanpa mengoordinasikan setiap perubahan di seluruh codebase. Namun, ada beberapa kekurangan: sistem terdistribusi memperkenalkan kompleksitas seputar kegagalan jaringan, konsistensi data, penemuan layanan, dan observabilitas yang tidak dihadapi oleh aplikasi monolitik.

Pola arsitektur lain yang harus dipahami oleh setiap insinyur meliputi arsitektur berbasis peristiwa (event-driven architecture), di mana komponen berkomunikasi melalui peristiwa yang dipublikasikan ke bus pesan daripada melalui panggilan sinkron langsung; arsitektur serverless, di mana komputasi dipecah menjadi fungsi-fungsi diskrit yang dieksekusi sesuai permintaan oleh infrastruktur penyedia cloud; dan arsitektur berlapis (layered architecture), di mana aplikasi diorganisasikan ke dalam lapisan horizontal — presentasi, logika bisnis, akses data — yang masing-masing hanya berkomunikasi dengan lapisan yang berdekatan.

3. Desain Data

Data adalah fondasi hampir setiap sistem software, dan keputusan yang dibuat tentang bagaimana data disusun, disimpan, diakses, dan dikelola memiliki konsekuensi jangka panjang yang lebih besar daripada hampir semua keputusan desain lainnya. Model data yang dirancang dengan buruk adalah salah satu pola hutang teknis paling mahal yang dapat diakumulasikan oleh suatu sistem, karena mengubah struktur data dalam produksi — terutama dalam sistem dengan volume data yang besar dan hubungan yang kompleks — mahal, berisiko, dan memakan waktu.

Keputusan utama pertama dalam desain data adalah pilihan antara model database relasional dan non-relasional (NoSQL). Database relasional mengatur data ke dalam tabel dengan skema yang ditentukan dan menegakkan hubungan antar tabel melalui kunci asing dan penggabungan (join). Database ini unggul dalam beban kerja di mana integritas data sangat penting, di mana hubungan antar entitas kompleks dan penting, dan di mana kueri ad-hoc dengan kekuatan penuh SQL diperlukan. PostgreSQL dan MySQL adalah database relasional yang paling umum digunakan dalam sistem produksi, dan untuk sebagian besar aplikasi, keduanya merupakan pilihan yang tepat.

Database NoSQL mengorbankan jaminan konsistensi dan fleksibilitas kueri model relasional sebagai ganti skalabilitas horizontal, fleksibilitas skema, dan karakteristik kinerja yang lebih sesuai dengan pola akses tertentu. Database dokumen seperti MongoDB menyimpan data sebagai dokumen fleksibel mirip JSON, ideal untuk konten dengan struktur variabel. Penyimpanan key-value seperti Redis unggul dalam pembacaan dan penulisan data sederhana berkecepatan tinggi yang diidentifikasi oleh kunci unik. Penyimpanan kolom lebar seperti Cassandra dioptimalkan untuk beban kerja penulisan berat di seluruh klaster terdistribusi. Mesin pencari seperti Elasticsearch memungkinkan pencarian teks lengkap di seluruh koleksi dokumen besar. Pilihan jenis database harus didorong oleh pola akses aktual aplikasi, bukan oleh keakraban atau tren.

4. Desain Domain

Desain domain adalah praktik pemodelan sistem software di sekitar konsep bisnis inti — domain — yang dilayani sistem tersebut, memastikan bahwa software tersebut mencerminkan ruang masalah dunia nyata secara akurat dan dengan cara yang dapat didiskusikan oleh para ahli domain dan insinyur menggunakan bahasa yang sama. Pendekatan ini adalah ide dasar dari Domain-Driven Design (DDD), yang diperkenalkan oleh Eric Evans dalam bukunya yang berpengaruh pada tahun 2003 dengan judul yang sama.

Artefak utama dari desain domain adalah model domain, yaitu representasi terstruktur dari entitas kunci, atributnya, dan hubungan serta aturan yang mengatur interaksi mereka. Model domain untuk sistem e-commerce mungkin mencakup entitas seperti Produk, Pelanggan, Pesanan, dan Pembayaran, dengan definisi yang jelas tentang apa yang diwakili oleh setiap entitas dalam bisnis, properti apa yang dimilikinya, dan bagaimana hubungannya dengan entitas lain. Disiplin untuk menjaga model domain tetap selaras dengan bagaimana pemangku kepentingan bisnis benar-benar berpikir dan berbicara tentang domain mereka — menggunakan kosakata yang sama dalam kode yang digunakan para ahli domain dalam percakapan — adalah apa yang disebut DDD sebagai "bahasa yang ada di mana-mana," dan ini adalah salah satu ide yang paling berharga secara praktis dalam desain software.

5. Skalabilitas

Skalabilitas adalah kemampuan suatu sistem untuk menangani peningkatan beban — lebih banyak pengguna, lebih banyak data, lebih banyak transaksi — tanpa penurunan kinerja atau memerlukan perancangan ulang arsitektur secara menyeluruh. Ini adalah salah satu konsep yang paling banyak dibahas dalam desain sistem justru karena mode kegagalannya sangat terlihat: sistem yang tidak dapat diskalakan akan gagal secara publik, di depan pengguna yang pertumbuhannya tidak dapat diakomodasi.

Ada dua pendekatan mendasar untuk penskalaan, yaitu penskalaan vertikal dan penskalaan horizontal. Penskalaan vertikal — menambahkan lebih banyak sumber daya (CPU, RAM, penyimpanan) ke mesin yang ada — adalah pendekatan paling sederhana dan tidak memerlukan perubahan pada kode aplikasi. Keterbatasannya adalah ada batasan seberapa kuat sebuah mesin tunggal dapat bekerja, dan server kelas atas jauh lebih mahal dibandingkan dengan peningkatan sumber dayanya. Penskalaan horizontal — menambahkan lebih banyak mesin ke sistem terdistribusi — secara teoritis dapat diskalakan tanpa batas, tetapi memerlukan aplikasi yang dirancang untuk berjalan di beberapa instance, yang menimbulkan kompleksitas seputar manajemen status, konsistensi data, dan koordinasi.

Caching adalah salah satu teknik skalabilitas paling berdampak yang tersedia bagi perancang sistem. Cache adalah lapisan penyimpanan cepat — biasanya penyimpanan data dalam memori seperti Redis atau Memcached — yang menyimpan hasil operasi yang memakan waktu lama sehingga dapat dikembalikan dengan cepat tanpa mengulangi pekerjaan yang mendasarinya. Kueri database yang membutuhkan waktu 200 milidetik dapat di-cache dan dikembalikan dalam waktu kurang dari satu milidetik pada permintaan berikutnya, secara dramatis mengurangi beban database dan meningkatkan waktu respons. Pembatalan cache — memastikan bahwa data yang di-cache dihapus atau diperbarui ketika data yang mendasarinya berubah — adalah salah satu masalah yang benar-benar sulit dalam sistem terdistribusi dan membutuhkan desain yang cermat.

Content Delivery Network (CDN) memperluas caching ke aset statis — gambar, JavaScript, CSS, video — dengan mendistribusikannya ke server edge yang berlokasi secara geografis dekat dengan pengguna. Pengguna di Singapura yang meminta gambar yang disimpan di server di Virginia akan mengalami latensi yang jauh lebih tinggi daripada pengguna di New York, kecuali jika gambar tersebut di-cache di server edge CDN di Singapura. CDN adalah alat skalabilitas fundamental untuk sistem dengan pengguna yang tersebar secara global.

Load balancing mendistribusikan permintaan masuk ke beberapa server backend, mencegah satu server menjadi bottleneck dan memungkinkan penskalaan horizontal layanan stateless. Load balancer menggunakan berbagai algoritma — round-robin, least connections, IP hash, weighted distribution — untuk mengalokasikan permintaan, dan mereka menyediakan pemeriksaan kesehatan yang menghapus server yang tidak sehat dari rotasi. Replika baca basis data — salinan basis data utama yang dapat melayani permintaan baca — adalah bentuk load balancing khusus basis data yang memungkinkan sistem yang banyak membaca untuk diskalakan dengan mendistribusikan lalu lintas baca ke beberapa instance basis data.

6. Keandalan

Keandalan adalah probabilitas bahwa suatu sistem menjalankan fungsi yang dimaksudkan dengan benar selama periode waktu tertentu dalam kondisi yang dinyatakan. Sistem yang andal tidak hanya berfungsi ketika semuanya berjalan dengan baik — sistem tersebut terus berfungsi, atau gagal dengan baik, ketika komponen gagal, ketika jaringan menjadi tidak andal, ketika data tidak terduga, atau ketika pola penggunaan menyimpang dari yang diantisipasi.

Desain sistem yang andal dimulai dengan penerimaan kebenaran mendasar, yaitu kegagalan bukanlah hal yang luar biasa. Dalam sistem yang cukup kompleks, komponen individual akan gagal. Server mengalami kerusakan, disk penuh, koneksi jaringan terputus, API eksternal menjadi tidak tersedia, dan software memiliki bug yang hanya muncul dalam kondisi tertentu. Sistem yang andal dirancang dengan harapan bahwa kegagalan ini akan terjadi dan dengan mekanisme untuk mendeteksi, menahan, dan memulihkannya tanpa menyebabkan gangguan sistem secara keseluruhan.

Redundansi adalah pola keandalan yang paling mendasar: memiliki beberapa instance komponen kritis sehingga kegagalan satu instance tidak menyebabkan kegagalan sistem secara keseluruhan. Konfigurasi replika-primer basis data, penyebaran multi-zona di lingkungan cloud, dan penyebaran multi-wilayah untuk persyaratan ketersediaan tertinggi semuanya menerapkan redundansi pada skala yang berbeda. Pertanyaan desain kunci untuk redundansi adalah mekanisme failover: bagaimana sistem mendeteksi bahwa komponen utama telah gagal, dan bagaimana sistem mengarahkan lalu lintas ke komponen redundan?

7. Ketersediaan

Ketersediaan adalah persentase waktu suatu sistem beroperasi dan mampu melayani permintaan. Hal ini terkait erat dengan keandalan tetapi diukur secara berbeda: keandalan berkaitan dengan keberhasilan operasi individual; ketersediaan berkaitan dengan apakah sistem aktif dan menerima permintaan sama sekali. Keduanya terkait — komponen yang tidak andal dan sering gagal mengurangi ketersediaan — tetapi secara konseptual berbeda.

Ketersediaan biasanya dinyatakan sebagai sejumlah angka sembilan: ketersediaan 99% berarti sistem tidak aktif sekitar 87,6 jam per tahun; 99,9% (tiga angka sembilan) berarti sekitar 8,7 jam per tahun; 99,99% (empat angka sembilan) berarti sekitar 52 menit per tahun; 99,999% (lima angka sembilan) berarti sekitar 5 menit per tahun. Setiap angka sembilan tambahan membutuhkan investasi rekayasa yang jauh lebih besar dan biasanya biaya infrastruktur yang lebih tinggi, sehingga tingkat ketersediaan target harus didorong oleh kebutuhan bisnis aktual daripada oleh tujuan yang ambisius.

Service Level Objectives (SLO) dan Service Level Agreements (SLA) adalah ekspresi formal dari komitmen ketersediaan. SLO adalah target internal — tingkat ketersediaan yang berkomitmen untuk dipertahankan oleh tim rekayasa. SLA adalah komitmen eksternal — tingkat ketersediaan yang dijanjikan kepada pelanggan, biasanya dengan konsekuensi (kredit layanan, penalti kontrak) jika komitmen tersebut tidak terpenuhi. Menetapkan SLO yang dapat dicapai dengan arsitektur saat ini, sambil menyisakan ruang yang berarti antara SLO dan SLA, adalah disiplin yang membantu tim mengelola kesenjangan antara aspirasi dan realitas.

8. Performa

Performa adalah seberapa cepat suatu sistem merespons permintaan dan seberapa efisien sistem tersebut menggunakan sumber daya komputasinya. Sistem yang memiliki ketersediaan tinggi tetapi lambat merespons bukanlah sistem yang berguna bagi pengguna yang bergantung padanya. Kinerja bukan hanya metrik teknis — kinerja terkait langsung dengan pengalaman pengguna, hasil bisnis, dan biaya operasional, menjadikannya pertimbangan desain yang layak mendapat perhatian berkelanjutan sepanjang siklus hidup sistem.

Latensi — waktu yang berlalu antara permintaan yang diajukan dan respons yang diterima — adalah metrik kinerja yang paling sering dilihat pengguna. Latensi biasanya dijelaskan dalam bentuk persentil: latensi p50 (median), latensi p95, dan latensi p99. Alasan mengapa persentil lebih disukai daripada rata-rata adalah karena sejumlah kecil permintaan yang sangat lambat dapat secara dramatis meningkatkan rata-rata tanpa menunjukkan masalah yang memengaruhi sebagian besar pengguna, sementara persentil p95 dan p99 mengungkapkan pengalaman latensi ekor — seberapa lambat sistem untuk 5% dan 1% permintaan paling lambat — yang seringkali berdampak tidak proporsional pada kepuasan pengguna.

Throughput — jumlah permintaan yang dapat diproses sistem per satuan waktu — adalah kebalikan dari latensi. Meningkatkan throughput seringkali membutuhkan teknik penskalaan horizontal yang dijelaskan di bagian skalabilitas. Hubungan antara throughput dan latensi diungkapkan oleh Hukum Little: jumlah rata-rata permintaan dalam suatu sistem sama dengan throughput dikalikan dengan latensi rata-rata. Hubungan matematis ini berarti bahwa mengurangi latensi meningkatkan throughput untuk sejumlah permintaan bersamaan tertentu, dan memahami hambatan dalam suatu sistem — komponen yang membatasi throughput — adalah langkah pertama untuk memperbaikinya.

9. Keamanan

Keamanan dalam desain sistem bukanlah fitur yang ditambahkan di akhir—ini adalah atribut kualitas yang harus dirancang sejak awal, karena asumsi keamanan yang dibuat selama desain awal menentukan kerentanan apa yang mungkin terjadi, dan memperbaiki arsitektur keamanan secara retrospektif jauh lebih sulit daripada mendesainnya dengan benar sejak awal.

Prinsip keamanan pertahanan berlapis menyatakan bahwa keamanan harus diimplementasikan pada beberapa lapisan, sehingga kegagalan satu kontrol keamanan saja tidak akan mengekspos seluruh sistem. Keamanan tingkat jaringan (firewall, VPN, segmentasi jaringan), keamanan tingkat aplikasi (otentikasi, otorisasi, validasi input), keamanan tingkat data (enkripsi saat diam dan saat transit), dan pemantauan dan deteksi (pencatatan, peringatan, deteksi anomali) semuanya harus diimplementasikan secara bersamaan, masing-masing menyediakan lapisan perlindungan yang mengkompensasi keterbatasan lapisan lainnya.

Otentikasi dan otorisasi adalah konsep keamanan paling mendasar dalam desain aplikasi. Otentikasi menjawab "siapa Anda?"—memverifikasi identitas entitas yang membuat permintaan. Otorisasi menjawab "apa yang diizinkan Anda lakukan?" — memverifikasi bahwa entitas yang diautentikasi memiliki izin untuk melakukan operasi yang diminta. Ini berbeda dan keduanya penting: sistem yang mengautentikasi pengguna tetapi gagal menegakkan otorisasi dengan benar memungkinkan setiap pengguna yang diautentikasi untuk mengakses data apa pun. Prinsip hak akses minimal — memberikan setiap entitas hanya izin minimum yang diperlukan untuk menjalankan fungsinya — adalah prinsip dasar desain otorisasi.

10. Kemudahan Pemeliharaan

Kemudahan pemeliharaan adalah kemudahan suatu sistem software untuk dipahami, dimodifikasi, diuji, dan diperluas dari waktu ke waktu. Ini adalah atribut kualitas yang paling langsung memengaruhi produktivitas jangka panjang tim pengembang, karena sistem yang tidak mudah dipelihara akan memperlambat setiap penambahan fitur, perbaikan bug, dan peningkatan kinerja selanjutnya. Sistem yang sulit diubah akan menumpuk hutang teknis lebih cepat daripada menumpuk nilai, dan tim yang bertanggung jawab atasnya akan menghabiskan sebagian besar waktu mereka untuk pemeliharaan daripada inovasi.

Modularitas — pengorganisasian suatu sistem ke dalam komponen-komponen yang berbeda dan terhubung secara longgar dengan antarmuka yang terdefinisi dengan baik — adalah prinsip dasar perangkat lunak yang mudah dipelihara. Sistem modular dapat dipahami satu komponen pada satu waktu, dimodifikasi dalam satu komponen tanpa perubahan yang menjalar ke komponen lain, dan diuji secara terisolasi. Kohesi tinggi (setiap modul memiliki satu tanggung jawab yang jelas) dan kopling rendah (modul saling bergantung sesedikit mungkin, dan hanya melalui antarmuka yang stabil) adalah properti desain yang mendefinisikan sistem modular.

Keterbacaan kode adalah prasyarat untuk kemudahan pemeliharaan. Kode lebih sering dibaca daripada ditulis, dan kode yang sulit dipahami akan sulit dimodifikasi dengan benar. Kode yang terdokumentasi sendiri — kode yang menggunakan nama yang bermakna, struktur yang jelas, dan fungsi-fungsi kecil yang diberi nama dengan baik yang mengungkapkan maksudnya — mengurangi beban kognitif pemahaman dan membuat kesalahan dalam modifikasi lebih mudah ditemukan. Konsistensi gaya kode — yang ditegakkan melalui linter dan formatter otomatis daripada diserahkan pada preferensi individu — adalah investasi praktis dalam keterbacaan yang memberikan keuntungan di setiap interaksi di masa mendatang dengan basis kode.

Manajemen dependensi — bagaimana suatu sistem mengelola hubungannya dengan pustaka eksternal, layanan, dan sistem lain — adalah dimensi pemeliharaan yang sering diremehkan. Sistem dengan banyak dependensi yang tidak terkelola akan menumpuk hutang pemeliharaan melalui konflik dependensi, kerentanan keamanan pada pustaka yang sudah usang, dan perubahan yang merusak pada dependensi yang tidak dirancang untuk diakomodasi oleh sistem. Penetapan versi dependensi, audit dan pembaruan dependensi secara teratur, dan perancangan lapisan abstraksi yang mengisolasi aplikasi inti dari API spesifik dependensi eksternal adalah praktik-praktik yang mengurangi biaya pemeliharaan dependensi eksternal.

11. Pengujian

Pengujian adalah praktik verifikasi sistematis bahwa sistem software berperilaku sesuai tujuan, baik saat digunakan dengan benar maupun saat dihadapkan pada input yang tidak terduga atau merugikan. Ini bukan aktivitas kualitas opsional yang dilakukan di akhir pengembangan — ini adalah disiplin rekayasa inti yang membentuk bagaimana sistem dirancang, seberapa yakin perubahan dapat dilakukan, dan seberapa cepat masalah dideteksi dan diselesaikan.

12. User Experience

User experience (UX) mungkin tampak tidak pada tempatnya dalam daftar konsep desain sistem — bukankah ini lebih menjadi perhatian desainer daripada insinyur? Namun kenyataannya, keputusan rekayasa yang dibuat selama desain sistem memiliki konsekuensi mendalam terhadap pengalaman pengguna, dan seorang insinyur yang memikirkan perspektif pengguna saat mendesain sistem menghasilkan hasil teknis yang lebih baik, bukan hanya pengalaman yang lebih baik.

Desain API adalah domain di mana keputusan rekayasa secara langsung menciptakan atau menghancurkan pengalaman developer — bentuk spesifik dari pengalaman pengguna di mana penggunanya adalah pengembang. API yang dirancang dengan baik dapat diprediksi, konsisten, dan mengikuti konvensi yang telah ditetapkan yang dapat diterapkan pengembang tanpa perlu membaca dokumentasi yang ekstensif. API REST yang menggunakan metode HTTP secara semantik, mengembalikan kode status yang sesuai, dan menggunakan konvensi penamaan yang konsisten lebih mudah dikonsumsi dan kurang rentan terhadap kesalahan dibandingkan API dengan perilaku yang tidak konsisten. API GraphQL yang dirancang dengan benar memungkinkan klien untuk meminta data yang tepat yang mereka butuhkan tanpa pengambilan data yang berlebihan atau kurang. Dalam kedua kasus tersebut, keputusan rekayasa desain API secara langsung menentukan produktivitas dan tingkat frustrasi setiap pengembang yang berintegrasi dengan sistem.

Penanganan dan penyampaian pesan kesalahan adalah masalah rekayasa lain yang memiliki implikasi UX yang signifikan. Sistem yang mengembalikan pesan kesalahan yang tidak jelas — "Terjadi kesalahan," "Permintaan gagal" — tidak memberikan informasi apa pun untuk membantu pengguna memahami apa yang salah atau apa yang dapat mereka lakukan. Sistem yang mengembalikan pesan kesalahan yang spesifik dan dapat ditindaklanjuti — "Alamat email yang Anda masukkan sudah terkait dengan akun; silakan masuk atau gunakan email lain" — memandu pengguna menuju penyelesaian masalah. Investasi rekayasa dalam penanganan kesalahan yang jelas dan spesifik terlihat langsung oleh pengguna dan secara bermakna memengaruhi pengalaman mereka.

13. Optimalisasi Biaya

Setiap keputusan rekayasa juga merupakan keputusan ekonomi, bahkan ketika dimensi tersebut tidak secara eksplisit dipertimbangkan. Pilihan jenis database, pilihan strategi caching, pilihan berapa banyak instance yang akan dijalankan dan dengan ukuran berapa, pilihan berapa banyak data yang akan disimpan dan berapa lama — semua ini adalah keputusan yang memiliki implikasi biaya langsung. Optimalisasi biaya dalam desain sistem adalah disiplin dalam membuat keputusan-keputusan ini dengan efisiensi ekonomi sebagai pertimbangan eksplisit di samping pertimbangan teknis.

Biaya infrastruktur cloud adalah kategori pengeluaran teknologi yang paling mudah dikendalikan untuk sebagian besar sistem modern. Penyedia cloud utama — AWS, Azure, dan GCP — mengenakan biaya untuk komputasi, penyimpanan, transfer jaringan, dan layanan terkelola dengan cara yang menciptakan daya ungkit desain yang signifikan. Instance yang dipesan dan kontrak penggunaan yang berkomitmen, di mana kapasitas dialokasikan untuk satu atau tiga tahun dengan imbalan diskon yang signifikan, dapat mengurangi biaya komputasi sebesar tiga puluh hingga enam puluh persen dibandingkan dengan harga sesuai permintaan untuk beban kerja yang dapat diprediksi. Instance spot dan VM preemptible, di mana kapasitas cloud yang tidak terpakai ditawarkan dengan diskon besar dengan catatan bahwa instance dapat dihentikan dengan pemberitahuan singkat, cocok untuk pemrosesan batch dan beban kerja yang toleran terhadap kesalahan yang dapat mentolerir gangguan.

14. Dokumentasi

Dokumentasi adalah sistem yang dibutuhkan setiap sistem software, tetapi sebagian besar tim teknik kurang berinvestasi di dalamnya. Ini adalah lapisan yang memungkinkan para insinyur yang tidak hadir saat keputusan desain dibuat untuk memahami apa yang diputuskan, mengapa diputuskan, dan apa implikasinya bagi siapa pun yang kemudian perlu mengubahnya. Tanpa dokumentasi yang memadai, pengetahuan terkonsentrasi di kepala orang-orang yang membuat keputusan awal, dan ketika orang-orang tersebut pergi atau pindah ke proyek lain, pengetahuan itu ikut hilang bersama mereka.

Architecture Decision Records (ADR) adalah format dokumentasi ringan yang menangkap konteks, keputusan, dan konsekuensi dari keputusan arsitektur yang signifikan. Misalnya, ADR untuk keputusan menggunakan PostgreSQL daripada MongoDB akan mencatat mengapa keputusan itu dibuat (kebutuhan akan integritas transaksional di seluruh entitas terkait), alternatif apa yang dipertimbangkan (MongoDB, DynamoDB, Cassandra), dan apa implikasinya (tim perlu mengelola migrasi skema seiring evolusi model data). ADR (Architectural Decision Review) mengubah keputusan arsitektur dari pertemuan sementara menjadi catatan permanen yang dapat dicari, yang dapat dikonsultasikan oleh anggota tim baru untuk memahami mengapa sistem dibangun seperti itu.

Dokumentasi API adalah salah satu investasi dokumentasi dengan pengembalian tertinggi untuk sistem yang mengekspos antarmuka ke tim lain atau developer eksternal. API yang tidak terdokumentasi memaksa konsumen untuk menebak perilaku atau membaca kode sumber untuk memahaminya — keduanya merupakan proses yang lambat dan rawan kesalahan. Alat dokumentasi API otomatis seperti OpenAPI/Swagger menghasilkan dokumentasi dari kode yang diberi anotasi, memastikan bahwa dokumentasi tetap sinkron dengan implementasi. Dokumentasi API interaktif yang memungkinkan pengembang untuk melakukan panggilan API nyata dari dalam peramban dokumentasi secara dramatis mengurangi waktu dari "membaca dokumen" hingga "berhasil mengintegrasikan."

15. Strategi Migrasi

Setiap sistem pada akhirnya perlu diubah dengan cara yang melampaui penambahan fitur baru — database perlu direstrukturisasi, monolit perlu dipecah menjadi layanan, infrastruktur perlu dipindahkan ke penyedia cloud yang berbeda, atau ketergantungan pihak ketiga perlu diganti. Migrasi ini termasuk aktivitas berisiko tertinggi dalam rekayasa sistem, karena menyentuh fondasi tempat semua hal lain berjalan, dan perlu direncanakan dan dieksekusi dengan ketelitian yang sama seperti desain sistem aslinya.

Migrasi skema databse adalah jenis migrasi yang paling sering dihadapi oleh sebagian besar sistem. Seiring berkembangnya persyaratan, model data yang benar di awal proyek jarang tetap benar selamanya. Kolom perlu ditambahkan, diganti namanya, atau dihapus; tabel perlu direstrukturisasi; relasi perlu diubah. Tantangannya adalah perubahan ini harus diterapkan pada basis data produksi yang secara aktif melayani permintaan, tanpa toleransi terhadap waktu henti atau kehilangan data.

Pola perluasan-kontraksi adalah pendekatan standar untuk migrasi database tanpa waktu henti. Pada fase perluasan, migrasi menambahkan struktur baru di samping struktur yang sudah ada tanpa menghapus apa pun — menambahkan kolom baru, tabel baru, atau relasi baru sambil mempertahankan struktur lama. Aplikasi diperbarui untuk menulis ke struktur lama dan baru secara bersamaan. Setelah data dalam struktur baru diverifikasi kebenarannya dan kelengkapannya, fase pengurangan menghapus struktur lama. Pendekatan dua fase ini memungkinkan setiap perubahan dilakukan secara independen dan dapat dibalik, tanpa memerlukan peralihan terkoordinasi.

Pola Strangler Fig adalah pendekatan standar untuk migrasi dari arsitektur monolit ke arsitektur microservices atau untuk mengganti sistem yang ada dengan sistem baru sambil mempertahankan ketersediaan berkelanjutan. Alih-alih mencoba migrasi "big bang" di mana sistem lama diganti sekaligus — pendekatan yang berisiko tinggi dan membutuhkan implementasi paralel lengkap sebelum migrasi dapat terjadi — Strangler Fig secara bertahap memindahkan fungsionalitas dari sistem lama ke sistem baru. Sebuah facade (seringkali berupa gateway API atau proxy) berada di depan kedua sistem dan mengarahkan permintaan ke sistem lama atau sistem baru tergantung pada sistem mana yang telah mengambil alih tanggung jawab untuk setiap bagian fungsionalitas. Seiring waktu, sistem baru menyerap semua fungsionalitas, dan sistem lama dihentikan penggunaannya.

Migrasi data — memindahkan volume data yang besar dari satu sistem penyimpanan ke sistem penyimpanan lain — membutuhkan pertimbangan yang cermat tentang konsistensi dan waktu henti. Teknik migrasi online memindahkan data sementara sistem sumber terus melayani lalu lintas, menyinkronkan perubahan yang dilakukan selama migrasi dengan menangkap dan memutarnya kembali ke tujuan. Pendekatan ini menghindari waktu henti tetapi secara teknis kompleks. Migrasi offline — menonaktifkan sistem sumber, menyalin semua data ke tujuan, dan kemudian mengaktifkan sistem baru — lebih sederhana tetapi membutuhkan perencanaan dan komunikasi mengenai jendela pemeliharaan yang dapat diakomodasi oleh pengguna dan pemangku kepentingan.

Feature flag merupakan alat yang sangat penting untuk mengelola migrasi dan secara umum mengurangi risiko perubahan sistem. Feature flag adalah saklar konfigurasi yang memungkinkan perubahan fitur atau perilaku diaktifkan atau dinonaktifkan tanpa menerapkan kode baru. Selama migrasi, feature flag memungkinkan jalur kode baru untuk diterapkan ke produksi dan diuji dalam skala kecil — diaktifkan untuk sebagian pengguna atau hanya untuk penguji internal — sebelum diaktifkan untuk semua pengguna. Pendekatan ini memisahkan penerapan kode dari aktivasi perilaku, memungkinkan peluncuran bertahap dan terkontrol yang dapat langsung dibatalkan jika muncul masalah.


Jadi, lima belas konsep dalam artikel ini bukanlah topik yang dapat dikuasai dalam satu akhir pekan atau sepenuhnya dipahami hanya dengan sekali baca. Konsep-konsep ini merupakan kosakata dasar dari praktik yang semakin mendalam seiring dengan setiap sistem yang Anda rancang, setiap analisis pasca-mortem yang Anda ikuti, dan setiap keputusan arsitektur yang Anda buat dan kemudian Anda jalani konsekuensinya. Insinyur yang telah merancang sistem yang gagal di bawah beban mempelajari skalabilitas secara berbeda dibandingkan dengan insinyur yang hanya membaca tentangnya. Insinyur yang telah memigrasikan basis data di lingkungan produksi memahami strategi migrasi dengan cara yang tidak dapat sepenuhnya disampaikan oleh teori apa pun.