24.4 Software Design dan Distributed System: Bahasa Sehari-hari Arsitek

Anda sedang rapat desain. Seorang engineer menunjukkan diagram yang terlihat rapi: kotak-kotak biru, garis panah, label yang jelas. Tapi ketika dia mulai menjelaskan alur datanya, Anda merasa ada yang ganjil. Setiap request akan memanggil tiga service secara berurutan, masing-masing menunggu response sebelum melanjutkan. Anda bertanya, "Kalau service kedua lambat, apa yang terjadi pada pengguna?" Engineer itu terdiam. "Dia nunggu," jawabnya akhirnya. "Berapa lama?" "Ya, sampai service kedua selesai."

Inilah momen di mana seorang arsitek berbeda dari engineer yang baik. Anda tidak hanya melihat diagram. Anda membayangkan perilaku sistem dalam kondisi nyata: ribuan pengguna mengirim request bersamaan, satu komponen mengalami gangguan, data harus konsisten di beberapa tempat. Kemampuan membayangkan ini bukan bakat bawaan. Ini hasil dari menguasai bahasa sehari-hari arsitek: software design dan distributed system.

Untuk memvisualisasikan bagaimana kedua pilar ini saling melengkapi, perhatikan diagram berikut.

flowchart TD A[Arsitek] --> B[Software Design] A --> C[Distributed System] B --> D[Modularity] B --> E[API Design] B --> F[Design Pattern & Refactoring] C --> G[Latency & Network] C --> H[Consistency] C --> I[Failure Mode] C --> J[Scalability] D --> K[Kemampuan Membayangkan Perilaku Sistem Nyata] E --> K F --> K G --> K H --> K I --> K J --> K

Software design adalah cara Anda berpikir tentang struktur code sebelum code itu ditulis. Modularity, misalnya, bukan sekadar membagi code ke dalam file-file terpisah. Modularity adalah keputusan tentang batas tanggung jawab. Satu modul mengurus satu hal, dan ia berkomunikasi dengan modul lain melalui antarmuka yang jelas. Ketika Anda bisa menjelaskan mengapa sebuah modul perlu dipecah atau digabung, Anda sedang berbicara dalam bahasa arsitek.

API design adalah perpanjangan dari modularity. API adalah janji. Ketika Anda merancang API, Anda sedang menentukan kontrak antara komponen: apa yang masuk, apa yang keluar, bagaimana error disampaikan, bagaimana versi dikelola. Arsitek yang baik tidak menulis API asal jadi. Ia memikirkan siapa konsumennya, bagaimana API itu akan berevolusi, dan apa yang terjadi jika kontrak dilanggar.

Design pattern dan refactoring adalah kosakata untuk perubahan. Pattern memberi nama pada solusi yang sudah teruji: Anda tidak perlu menemukan ulang cara menangani event atau mengelola state. Cukup sebut "observer pattern" atau "event sourcing", dan tim langsung paham pendekatannya. Refactoring adalah kemampuan melihat kapan struktur code mulai usang dan bagaimana memperbaikinya tanpa mengubah perilaku. Arsitek tidak menghindari perubahan code. Ia menjaga agar code tetap sehat dan siap berubah.

Distributed system membawa bahasa ini ke level yang lebih luas. Latency adalah kenyataan yang tidak bisa dihindari. Ketika dua service berkomunikasi melalui jaringan, setiap milidetik berarti. Arsitek harus bisa membedakan: mana panggilan yang harus sinkron, mana yang cukup asynchronous, mana yang bisa di-cache, mana yang perlu di-batch. Latency bukan angka di dashboard. Latency adalah pengalaman pengguna yang menunggu.

Consistency adalah pilihan. Tidak semua data harus konsisten setiap saat. Arsitek perlu tahu kapan eventual consistency cukup, kapan strong consistency diperlukan, dan bagaimana trade-off di antara keduanya. Keputusan ini tidak bisa diambil oleh engineer yang hanya melihat satu service. Keputusan ini membutuhkan pemahaman tentang alur data dari ujung ke ujung.

Failure mode adalah latihan mental yang paling penting. Arsitek yang matang tidak bertanya "apakah sistem ini akan gagal?" Ia bertanya "ketika sistem ini gagal, bagaimana dampaknya?" Satu service mati, apa yang terjadi? Database lambat, bagaimana aplikasi merespons? Network terputus, apakah data aman? Kemampuan membayangkan skenario kegagalan dan merancang mitigasi adalah yang membedakan arsitek dari pelaksana.

Scalability adalah hasil dari semua keputusan sebelumnya. Sistem yang skalabel bukan sistem yang bisa menangani beban besar. Sistem yang skalabel adalah sistem yang tidak perlu dirombak total ketika beban bertambah. Arsitek merancang dengan asumsi bahwa beban akan tumbuh, dan ia memastikan setiap komponen bisa diperluas secara independen.

Bahasa ini tidak bisa dipelajari dalam semalam. Tapi Anda bisa mulai dari satu hal: setiap kali melihat desain, tanyakan "apa yang terjadi jika..." Latihan ini akan mengubah cara Anda membaca diagram, menulis code, dan berdiskusi dengan tim. Dan ketika Anda sudah fasih, Anda tidak perlu lagi bertanya apakah sebuah keputusan arsitektural tepat. Anda akan melihatnya langsung, seperti Anda melihat bahwa query yang diusulkan engineer junior tadi akan memblokir tabel produksi.

Setelah bahasa ini dikuasai, langkah berikutnya adalah memahami di mana sistem itu berjalan. Cloud, infrastruktur, dan keamanan bukan urusan operasional semata. Mereka adalah batasan dan peluang yang membentuk keputusan desain Anda.