Cabut dan Jalan — Desain Hub-Spoke yang Lahir untuk Keterputusan

Mari Mulai dari Hub-Spoke yang Sudah Anda Kenal

Anda mungkin belum pernah mendengar istilah "topologi Hub-Spoke," tetapi Anda menggunakannya setiap hari.

Buka peta rute maskapai manapun. Anda akan melihat beberapa node raksasa — Jakarta, Surabaya, Denpasar — yang memancarkan rute-rute padat ke puluhan kota yang lebih kecil. Node besar adalah Hub. Kota kecil adalah Spoke.

Mengapa maskapai mendesainnya seperti ini? Karena jika setiap kota terbang langsung ke semua kota lainnya, 30 kota membutuhkan 435 rute. Tetapi jika semua kota terbang dulu ke Hub, lalu transit dari Hub, hanya dibutuhkan 30 rute. Hub adalah koordinator yang menangani penjadwalan, transit, dan alokasi sumber daya secara terpusat.

Pola ini juga umum dalam sistem informasi: satu node pusat mengoordinasikan banyak node tepi. Data terpusat di Hub, Spoke menangani operasi garis depan.

Tetapi Hub-Spoke tradisional memiliki satu asumsi fatal: Hub selalu online.

Penerbangan bisa menunggu bandara Hub dibuka kembali. Paket bisa menunggu pusat penyortiran memprosesnya. Tetapi di lokasi bencana, jika Hub down, pasien tidak bisa menunggu.

Hub-Spoke xGrid membuat dua perubahan konsep yang krusial: setiap Spoke adalah sistem lengkap, bukan sekadar terminal. Dan — Spoke manapun dapat mengambil alih menjadi Hub baru di lapangan.

Keterputusan Bukan Kegagalan, Melainkan Kondisi yang Diharapkan

Sistem tradisional memperlakukan keterputusan jaringan sebagai "kegagalan" — mendeteksi keterputusan, memicu peringatan, menunggu pemulihan.

xGrid mendesain keterputusan sebagai "kondisi normal." Setiap perangkat adalah sistem lengkap — punya sistem sumber dayanya sendiri, basis datanya sendiri. Keterputusan hanya berarti kehilangan kemampuan sinkronisasi sementara, bukan kehilangan kemampuan beroperasi.

Inilah perbedaan terbesar antara Hub-Spoke versi xGrid dengan versi maskapai: Spoke bukan terminal yang menunggu perintah Hub, melainkan sistem lengkap yang bisa beroperasi secara mandiri. Yang disediakan Hub adalah koordinasi, bukan kapabilitas.

Setiap Node Adalah Sistem Lengkap

Inilah konsep paling krusial dalam seluruh desain: setiap perangkat, saat keluar dari pabrik, adalah sebuah stasiun medis yang lengkap.

Peran tidak ditentukan oleh perangkat keras. Mesin yang sama bisa menjadi Hub, bisa juga menjadi Spoke — perbedaannya ada pada peran yang dimainkannya, bukan pada komponen apa dirinya. Ini berarti Anda tidak perlu menyiapkan "mesin khusus Hub" dan "mesin khusus Spoke." Yang disimpan di gudang bukan "dua jenis komponen," melainkan "setumpuk suku cadang yang identik." Satu unit rusak, ambil unit baru dari kotak, sambungkan, lanjutkan.

Deployment terkecil hanya membutuhkan satu mesin, tanpa infrastruktur jaringan apapun — satu sumber daya listrik, satu tablet, itulah sebuah stasiun medis yang lengkap. Perlu memperluas? Bawa satu unit lain dan sambungkan, ia menjadi Spoke baru. Satu mesin bisa menopang pos medis garis depan; seperangkat mesin bisa menopang sebuah pusat medis. Desain yang sama, menyesuaikan skala.

Dua Lapisan Jaringan yang Independen — Satu Putus, yang Lain Menopang

Deployment xGrid adalah dua lapisan jaringan yang saling independen yang ditumpuk: satu lapisan menangani operasi (setiap mesin menyediakan cakupan nirkabelnya sendiri, tablet cukup terhubung ke mesin terdekat untuk bekerja), satu lapisan menangani sinkronisasi antar stasiun.

Kuncinya adalah kedua lapisan ini sepenuhnya independen. Lapisan yang menangani sinkronisasi putus? Tablet di setiap stasiun terus beroperasi, hanya sinkronisasi antar stasiun yang hilang sementara. Cakupan nirkabel suatu mesin rusak? Sinkronisasi tetap berjalan, tablet di area itu cukup beralih ke cakupan terdekat.

Satu lapisan putus, lapisan lain menopang. Inilah wujud dari "keterputusan adalah kondisi yang diharapkan" ketika diterapkan pada desain jaringan.

Spoke Manapun Bisa Mengambil Alih

Inilah kemampuan paling kuat dalam seluruh desain, dan ia memiliki dua wujud.

Mengambil dan membawa pergi secara aktif. Dalam insiden korban massal, pusat komando memberi tahu bahwa muncul titik konsentrasi korban kedua sepuluh kilometer jauhnya, dan perlu segera membuka stasiun medis kedua. Anda berjalan ke salah satu Spoke, memasukkannya ke dalam ransel bersama baterai dan tablet, tiba di lokasi baru lalu menyambungkan daya — ia langsung menjadi stasiun medis baru yang lengkap dan beroperasi mandiri, membawa semua data pasien yang dimiliki Hub asli hingga beberapa saat lalu. Tidak perlu perencanaan sebelumnya, tidak perlu mesin khusus.

Mengambil alih secara pasif. Perangkat keras Hub rusak — sumber dayanya terbakar, atau tertimpa langit-langit yang runtuh. Setiap Spoke terus-menerus memantau apakah Hub masih hidup. Setelah memastikan Hub benar-benar offline, operator menunjuk salah satu Spoke untuk mengambil alih. Karena setiap Spoke memegang satu salinan cadangan yang hampir real-time, kehilangan data pasien setelah pengambilalihan memiliki batas atas yang jelas; pada puncak masuknya korban, operator bahkan bisa menekan batas ini menjadi lebih rendah secara manual.

Pengambilalihan promosi adalah sebuah operasi berhasil seluruhnya atau gagal seluruhnya — entah mengambil alih sepenuhnya, atau kembali ke keadaan semula, tidak akan muncul produk setengah jadi yang "macet di tengah promosi."

Mengapa keputusan manusia, bukan otomatis oleh mesin? Karena di lingkungan terputus, Anda tidak bisa memastikan apakah Hub benar-benar rusak, atau hanya kabel jaringan yang longgar. Jika dua Spoke mengambil alih secara otomatis pada saat bersamaan, Anda akan mendapatkan dua Hub yang masing-masing menerima pasien — ini disebut split-brain, dan menggabungkan data setelahnya akan menjadi bencana. Maka pengambilalihan harus merupakan keputusan manusia yang disengaja.

Hub Zombi dan Perlindungan Split-Brain — Mengandalkan Mekanisme, Bukan Disiplin Diri

"Jangan promosikan dua unit secara bersamaan" adalah sebuah aturan. Tetapi aturan akan dilanggar di lokasi bencana — bagaimana jika seseorang menekan sekali lagi dalam kekacauan?

Maka mengandalkan disiplin diri saja tidak cukup. Desain xGrid membuat Hub yang kedaluwarsa menyingkir dengan sendirinya: ketika Hub lama yang sempat rusak lalu disambungkan kembali ke daya melakukan boot ulang, ia akan mendapati bahwa di lapangan sudah ada Hub yang "lebih baru satu putaran" sedang beroperasi — ia tidak akan berusaha merebut kembali kedaulatan, melainkan otomatis turun menjadi Spoke. Tidak perlu manusia mematikannya.

Demikian pula, jika sebuah Spoke saat menyambung kembali sekaligus melihat dua "stasiun utama" yang saling bertentangan, ia tidak akan asal memilih satu, melainkan berhenti dan meminta konfirmasi manusia. Setiap deployment juga saling terisolasi, Spoke Anda tidak akan tersambung secara tidak sengaja ke Hub deployment sebelah.

Mekanisme ini tidak bisa mencegah split-brain seratus persen — jika dua subgrup yang sepenuhnya terputus masing-masing mengambil alih satu Hub, Anda memang akan mendapatkan dua Hub yang independen. Tetapi ia menjamin: begitu kedua subgrup tersambung kembali ke jaringan, yang lebih lama akan otomatis menyingkir. Persoalannya tidak pernah "bagaimana mencegah split-brain selamanya," melainkan "bagaimana mengoreksinya secara otomatis secepat mungkin setelah split-brain terjadi."

Resolusi Konflik: Bergantung pada Sifat Data

Dua perangkat selama periode terputus masing-masing memodifikasi data yang sama, lalu saat tersambung kembali bagaimana?

Jawabannya bergantung pada apa data itu. Yang bisa diakumulasi, diakumulasi — stasiun utama mengonsumsi 5 kasa, stasiun satelit mengonsumsi 3, jawaban yang benar adalah 8 yang dikonsumsi, bukan "mengikuti yang lebih baru" (itu akan kehilangan salah satu sisi). Catatan yang tidak dapat dimodifikasi (tanda vital, serah terima) disimpan di kedua sisi.

Yang terpenting adalah data yang biaya kesalahannya terlalu tinggi sehingga tidak boleh diselesaikan secara otomatis: kantong darah, obat terkontrol. Satu kantong darah ditandai "telah dikeluarkan" oleh dua stasiun secara bersamaan, ini bukan persoalan yang bisa diselesaikan dengan timestamp. Sistem akan menandainya sebagai konflik, menunggu petugas yang bertanggung jawab mengonfirmasi secara langsung.

Menjadikan "penilaian manusia" sebagai jawaban yang benar untuk situasi tertentu, dan bukan cacat yang perlu dihilangkan — inilah garis pemisah krusial saat mendesain untuk lingkungan berisiko tinggi.

Filosofi Desain: Lahir untuk Keterputusan

Sebagian besar sistem dimulai dari premis "jaringan dapat diandalkan," lalu menambahkan penanganan pengecualian untuk situasi yang tidak dapat diandalkan.

xGrid dimulai dari premis "jaringan tidak dapat diandalkan," lalu melakukan optimasi untuk situasi yang dapat diandalkan.

Pembalikan ini menghasilkan keputusan desain yang sepenuhnya berbeda:

• Setiap node adalah sistem lengkap (bukan terminal yang hanya bisa menampilkan layar)
• Peran ditentukan oleh peran yang dimainkan, bukan oleh perangkat keras (tidak perlu "mesin Hub khusus")
• Sinkronisasi adalah operasi batch berkala (bukan koneksi real-time yang terus-menerus)
• Resolusi konflik adalah perilaku default (bukan penanganan pengecualian)
• Penilaian manusia adalah jawaban yang benar untuk situasi tertentu (bukan cacat yang perlu dihilangkan)
• Pengambilalihan adalah keputusan manusia yang disengaja (karena split-brain lebih berbahaya daripada menunggu)
• Tetapi Hub yang kedaluwarsa menyingkir secara otomatis (karena ini adalah fakta, bukan disiplin diri)

Kabel jaringan tertendang lepas bukanlah kegagalan. Switch terbentur rusak bukanlah kiamat. Hub terbakar bukanlah akhir.

Semuanya hanyalah pemicu bagi penataan ulang topologi.

---

Bacaan lanjutan: "Offline-First" Bukan "Offline Sekadar Cukup" · ISBAR Lebih dari Sekadar Format Serah Terima — Ketika Tradisi Lisan Bertemu Data Terstruktur