Desktop Client-Server Architecture

Beberapa tahun lalu, saya terlibat dalam proyek sistem informasi rumah sakit. Waktu itu, setiap komputer di bagian pendaftaran, kasir, dan apotek harus bisa mengakses data pasien yang sama. Kalau ada pasien pindah dari poli ke apotek, petugas di apotek harus bisa melihat resep yang baru saja ditulis dokter. Solusi yang paling masuk akal saat itu: pasang satu server di ruang server, lalu setiap komputer di rumah sakit terhubung ke server itu lewat jaringan lokal.

Awalnya berjalan mulus. Tapi begitu jumlah pasien bertambah, server mulai kewalahan. Komputer di kasir terasa lambat saat menyimpan data pembayaran. Kalau server mati mendadak—entah karena listrik padam atau hard disk rusak—semua komputer tidak bisa mengakses data sama sekali. Rumah sakit kembali ke mode manual: tulis resep di kertas, catat pembayaran di buku besar. Baru setelah server hidup lagi, petugas harus entry data ulang.

Situasi ini adalah contoh klasik dari pola arsitektur yang disebut desktop client-server. Pola ini lahir dari kebutuhan sederhana: banyak pengguna di tempat yang sama perlu mengakses data yang sama secara bersamaan.

Masalah yang Diselesaikan

Sebelum pola ini populer, aplikasi desktop biasa menyimpan data di file lokal. Setiap komputer punya datanya sendiri. Kalau dua orang di bagian berbeda perlu data yang sama, mereka harus saling kirim file atau mencetak laporan. Data jadi tidak konsisten, backup harus dilakukan per komputer, dan tidak ada kontrol akses yang terpusat.

Desktop client-server menyelesaikan masalah ini dengan memisahkan tanggung jawab. Satu komputer menjadi server yang menyimpan dan mengelola data. Komputer lain menjadi client yang menampilkan antarmuka dan mengirim permintaan. Data tidak lagi tersebar. Semua perubahan terjadi di satu tempat.

Komponen Utama

Dalam arsitektur ini, ada tiga blok utama yang saling terhubung.

Desktop Client adalah komputer yang dipakai pengguna langsung. Di dalamnya berjalan aplikasi desktop yang menangani antarmuka pengguna, validasi input sederhana, dan kadang menyimpan cache lokal agar tidak perlu request terus-menerus ke server. Client bisa berupa thick client yang menjalankan banyak logika sendiri, atau thin client yang hanya menampilkan hasil olahan server.

Network adalah jalur komunikasi antara client dan server. Biasanya berupa LAN untuk jaringan lokal atau WAN jika client dan server terpisah lokasi. Protokol yang umum dipakai adalah TCP/IP. Kualitas jaringan sangat memengaruhi pengalaman pengguna—semakin lambat jaringan, semakin lambat respon aplikasi.

Central Server adalah jantung dari arsitektur ini. Server menjalankan application logic, database server, dan kadang file server. Semua permintaan dari client diproses di sini. Server juga yang mengatur hak akses, menjaga konsistensi data, dan menjalankan backup. Karena semua beban ada di server, spesifikasi hardware server biasanya jauh lebih tinggi daripada client.

Alur Kerja

Cara kerja pola ini cukup sederhana. Client mengirim request melalui jaringan. Request bisa berupa perintah SQL, panggilan prosedur, atau format lain yang disepakati. Server menerima request, memprosesnya—misalnya membaca atau menulis data di database—lalu mengirim response kembali ke client.

Alurnya linear: client request, jaringan mengirim, server memproses, response kembali. Tidak ada mekanisme push dari server. Client harus meminta data dulu sebelum server mengirimkannya. Ini yang membedakan pola ini dari arsitektur real-time atau event-driven.

Kapan Pola Ini Cocok Dipakai

Desktop client-server masih menjadi pilihan tepat untuk beberapa skenario. Pertama, aplikasi internal perusahaan yang dipakai oleh puluhan hingga ratusan pengguna dalam satu gedung atau kampus. Contohnya sistem ERP, aplikasi akuntansi, atau sistem manajemen rumah sakit.

Kedua, aplikasi yang membutuhkan kontrol data ketat. Karena data terpusat, tim IT bisa mengatur backup rutin, menerapkan kebijakan akses, dan memonitor penggunaan secara terpusat. Ini penting di industri yang diaudit seperti perbankan atau layanan kesehatan.

Ketiga, lingkungan dengan koneksi internet tidak stabil. Karena client dan server berada dalam jaringan lokal, aplikasi tetap bisa berjalan meskipun koneksi internet ke luar sedang bermasalah. Latensi juga lebih rendah karena data tidak perlu keluar gedung.

Trade-off, Batasan, dan Risiko Operasional

Pola ini punya kelemahan yang perlu dipahami sebelum memutuskan menggunakannya.

Server menjadi titik kegagalan tunggal. Kalau server mati, semua client tidak bisa bekerja. Tidak ada mekanisme failover otomatis kecuali sudah disiapkan clustering atau server cadangan. Risiko ini harus diantisipasi dengan UPS, backup berkala, dan rencana recovery.

Skalabilitas terbatas. Menambah client berarti menambah beban server. Pada titik tertentu, server tidak sanggup melayani semua request. Solusi yang paling umum adalah vertical scaling: upgrade CPU, RAM, atau storage server. Clustering dengan load balancer bisa dilakukan, tetapi kompleksitasnya naik drastis.

Ketergantungan pada jaringan. Aplikasi tidak bisa berfungsi jika jaringan bermasalah. Kabel putus, switch rusak, atau konfigurasi jaringan salah bisa melumpuhkan operasi. Tim infrastruktur harus memastikan jaringan memiliki redundansi.

Biaya operasional server tinggi. Server perlu perawatan rutin, upgrade berkala, dan tenaga khusus untuk mengelolanya. Untuk organisasi kecil, biaya ini bisa memberatkan.

Implikasi Praktis untuk Tim Engineering

Jika tim Anda memutuskan menggunakan pola ini, ada beberapa hal yang perlu diperhatikan.

Pertama, desain client dengan asumsi jaringan tidak selalu cepat. Gunakan local cache untuk data yang jarang berubah. Beri indikasi visual saat aplikasi sedang menunggu response server. Jangan sampai pengguna mengira aplikasi hang padahal sebenarnya sedang menunggu data.

Kedua, rencanakan strategi update aplikasi client. Karena aplikasi berjalan di banyak komputer, mengupdate versi baru bisa merepotkan. Pertimbangkan mekanisme auto-update atau setidaknya notifikasi ke pengguna saat versi baru tersedia.

Ketiga, siapkan prosedur operasional yang jelas. Siapa yang bertanggung jawab saat server mati di luar jam kerja? Bagaimana cara restore data dari backup? Berapa lama target recovery time? Prosedur ini harus ditulis dan diuji, bukan hanya ada di kepala satu orang.

Keempat, monitor server secara proaktif. Pantau penggunaan CPU, memory, disk I/O, dan koneksi jaringan. Buat alert sebelum resource mencapai batas. Dengan monitoring yang baik, tim bisa melakukan upgrade sebelum server benar-benar kewalahan.

Desktop client-server bukan arsitektur yang paling modern atau paling fleksibel. Tapi untuk skenario yang tepat—aplikasi internal dengan pengguna tetap, data terpusat, dan jaringan lokal yang stabil—pola ini masih sangat relevan. Yang penting adalah memahami batasannya dan menyiapkan operasional yang matang sebelum benar-benar dipakai production.