Sistem idMe Selalu Down. Ini Solusi Dari Perspektif Developer
Published:
Updated:
Baru-baru ini saya terbaca berita tentang guru stress sebab sistem idMe (Sistem Pengurusan Identiti) selalu down.
Sebagai system developer, perkara pertama yang terlintas dalam kepala saya memang “kesian guru”.
Saya terus fikir satu benda.
Ini sebenarnya masalah teknikal yang perlu diselesaikan.
Masalah Sebenar Bukan Guru Lambat Isi Data
Situasinya selalu sama.
Ratusan ribu guru login serentak untuk key in data.
Apa jadi?
Server tak mampu handle trafik.
Result:
-
loading lama
-
500 error
-
login gagal
-
guru terpaksa berjaga malam nak isi data
Ini bukan masalah baru. Banyak sistem besar hadapi benda yang sama.
Bila semua orang tekan server yang sama pada waktu yang sama, sistem akan collapse.
“Tambah Server” Bukan Penyelesaian Bijak
Biasanya solusi yang dicadangkan ialah:
tambah server
Ya, itu boleh bantu.
Tapi itu juga bermaksud:
-
kos server meningkat
-
kos maintenance meningkat
-
dan masih tak menyelesaikan isu traffic spike
Masalah sebenar ialah terlalu banyak concurrent request pada satu masa.
Dalam dunia bisnes, kita biasanya guna pendekatan lain.
Offline-first architecture.
Penyelesaian Yang Lebih Practical: PWA + Background Sync
Daripada semua guru bergantung sepenuhnya pada server pusat, kita boleh jadikan browser mereka sebagai buffer sementara.
Caranya dengan menggunakan Progressive Web App (PWA).
Flow dia jadi macam ini.
-
Guru buka sistem idMe seperti biasa
-
Web app disimpan dalam browser mereka
-
Jika server slow atau down, guru masih boleh isi data
-
Data disimpan sementara dalam browser menggunakan IndexedDB
-
Bila server kembali normal, browser akan hantar data tersebut secara automatik
Guru tak perlu refresh.
Tak perlu login semula.
Tak perlu berjaga malam.
Sistem tetap responsive walaupun server tengah sakit.
Apa Yang Berlaku Di Belakang Tabir
Developer boleh implement logic ini menggunakan Service Worker.
Service worker akan bertindak sebagai layer di antara browser dan server.
Jika request gagal, data tidak hilang. Ia disimpan dulu secara lokal.
Contoh kes yang lebih mudah difahami ialah sistem kehadiran staff.
Request POST ke server akan dipintas.
Jika server gagal respon, data akan disimpan ke IndexedDB dan dimasukkan ke dalam queue untuk dihantar kemudian.
Contoh ringkas logiknya seperti ini:
self.addEventListener('fetch', (event) => {
if (event.request.method === 'POST') {
event.respondWith(
fetch(event.request.clone()).catch(async () => {
const data = await event.request.clone().json()
await saveToIndexedDB('offline-queue', data)
await self.registration.sync.register('sync-data')
return new Response(JSON.stringify({
status: "queued"
}))
})
)
}
})
Bila internet stabil semula, service worker akan sync semua data tersebut ke server.
Automatik.
Kenapa Sistem Kerajaan Patut Gunakan Pendekatan Ini
Dengan model ini:
Cikgu menang
Mereka boleh isi data tanpa stress walaupun server slow.
Server juga menang
Sebab tidak perlu handle semua request pada masa yang sama.
Dan paling penting.
Sistem jadi lebih resilient.
Realitinya, sistem besar memang akan ada downtime sekali sekala.
Soalan sebenar bukan “macam mana nak elakkan downtime”.
Soalan yang lebih penting ialah:
macam mana sistem masih boleh berfungsi walaupun downtime berlaku.
Penutup
Isu sistem down bukan isu baru.
Tapi cara kita bina sistem hari ini masih banyak yang guna pendekatan lama.
Teknologi seperti PWA, background sync, dan offline-first architecture sebenarnya sudah lama wujud. Cuma jarang digunakan dalam sistem berskala besar seperti ini.
Kadang-kadang penyelesaiannya bukan tambah server.
Kadang-kadang kita cuma perlu ubah cara sistem itu direka dari awal.
Of course, saya cuma seorang system builder kecil yang suka fikir macam mana nak selesaikan masalah menggunakan teknologi.
Kalau kebetulan vendor atau team yang urus sistem ini terbaca artikel ini dan rasa idea ini masuk akal, silakan guna saja. Tak perlu tanya pun tak apa. Kalau nak bagi shoutout kecil pun saya tak kisah. Haha.
Yang penting kalau pendekatan ini boleh kurangkan stress guru, itu sudah cukup baik.
Guru sepatutnya fokus mengajar dan bantu pelajar belajar. Bukan bergelut dengan loading screen atau sistem yang asyik down.
Kalau teknologi boleh hilangkan masalah kecil seperti ini, mungkin guru boleh gunakan tenaga itu untuk perkara yang lebih penting.
Seperti mendidik generasi seterusnya.
