Pola yang Sudah Anda Kenal
Anda mungkin belum pernah mendengar istilah "topologi Hub-Spoke," tetapi Anda menggunakannya setiap hari.
Buka peta rute maskapai manapun. Beberapa node besar -- Jakarta, Surabaya, Denpasar -- memancarkan puluhan koneksi ke kota-kota lebih kecil. Node besar adalah Hub. Kota kecil adalah Spoke. Alih-alih terbang langsung dari setiap kota ke semua kota lainnya (yang membutuhkan 435 rute untuk 30 kota), semua lalu lintas mengalir melalui beberapa hub. Lebih sedikit rute, lebih banyak koordinasi, jauh lebih efisien.
Point-to-point (atas) vs Hub-and-spoke (bawah): routing melalui hub pusat mengurangi koneksi secara drastis. Sumber: Wikipedia (domain publik)
Logistik bekerja dengan cara yang sama. FedEx mengarahkan semuanya melalui Memphis. Sebuah paket dari Taipei ke Kaohsiung mungkin terbang melewati Memphis dulu -- terlihat absurd, tetapi penyortiran terpusat lebih efisien daripada relay titik ke titik.
Tetapi Hub-Spoke tradisional memiliki asumsi fatal: Hub selalu online. Penerbangan bisa menunggu bandara hub dibuka kembali. Paket bisa menunggu pusat penyortiran. Tetapi dalam insiden korban massal, jika Hub down, pasien tidak bisa menunggu.
Hub-Spoke xGrid membuat dua modifikasi kritis: setiap Spoke adalah sistem lengkap, bukan hanya terminal. Dan -- setiap Spoke dapat mempromosikan dirinya menjadi Hub baru dalam hitungan menit.
Tata Letak Fisik: Satu Tulang Punggung, Banyak Satelit
Deployment xGrid adalah topologi yang dapat diskalakan dibangun di sekitar switch Ethernet:
┌─────────────────────┐
│ Hub A │
│ CIRS + MIRS + HIRS │
│ WiFi Hotspot │
│ mDNS broadcast │
└──────────┬──────────┘
│
┌─────────┴─────────┐
│ Ethernet Switch │
└──┬────┬────┬────┬─┘
│ │ │ │
┌──┴┐┌──┴┐┌──┴┐┌──┴┐
│ B ││ C ││ D ││ E │ ← Spokes
└───┘└───┘└───┘└───┘
Masing-masing punya WiFi hotspot sendiri
Masing-masing menjalankan MIRS penuh
Masing-masing menyimpan snapshot CIRS terbaru
Hub menjalankan sistem sumber daya (CIRS), sistem klinis (MIRS), dan inventaris (HIRS). Spoke terhubung ke Hub melalui switch Ethernet, masing-masing menjalankan MIRS untuk mengelola inventaris stasiun sendiri.
Dua lapisan jaringan terpisah, secara desain: Ethernet untuk sinkronisasi data antar stasiun. WiFi untuk operasi klinis di setiap stasiun. Satu bisa gagal tanpa memengaruhi yang lain.
Setiap RPi Adalah Sistem Lengkap — Golden Image
Ini adalah keputusan desain paling penting dalam seluruh arsitektur: setiap Raspberry Pi dikirim dengan semuanya terinstal.
CIRS (sumber daya), MIRS (klinis), HIRS (inventaris) — semuanya ada di setiap kartu SD. Peran tidak ditentukan oleh perangkat keras. Ditentukan oleh satu file konfigurasi: /etc/xgrid/role.conf. Ubah satu field dan Spoke menjadi Hub.
Ini berarti Anda tidak menyimpan stok "unit Hub" dan "unit Spoke." Anda menyimpan suku cadang identik. Unit manapun bisa menggantikan unit manapun.
Deployment Berjenjang — Dari Pos Depan hingga Pusat Medis
| Tingkat | Konfigurasi | Konektivitas | Tablet bersamaan |
|---|---|---|---|
| Pusat Medis | 1 Hub + 4 Spoke | Switch 8 port | ~75 |
| Rumah Sakit Regional | 1 Hub + 3 Spoke | Switch 5 port | ~60 |
| Rumah Sakit Kabupaten | 1 Hub + 1 Spoke | Kabel langsung | ~30 |
| Pos Depan | 1 Mandiri | Tidak diperlukan | ~15 |
Golden Image yang sama bekerja di semua tingkat. Perbedaannya adalah berapa unit yang Anda deploy dan peran apa yang Anda tetapkan — bukan software yang mereka bawa.
Terputus Bukan Kegagalan — Itu Kondisi yang Diharapkan
Di xGrid, kehilangan koneksi jaringan tidak memicu apapun yang terlihat oleh staf klinis. Kedua sistem terus beroperasi dengan fungsionalitas penuh — basis data sendiri, antarmuka klinis sendiri, stasiun tablet sendiri.
Prinsip desain fundamental: setiap Spoke adalah sistem lengkap. Hub menyediakan koordinasi, bukan kapabilitas. Ketika koordinasi hilang, satu-satunya yang berubah adalah waktu sinkronisasi.
Sinkronisasi Tiga Fase
Fase 1 — Verifikasi: Hub memeriksa kesehatan setiap Spoke. Tidak ada respons dalam 30 detik — lewati. Pemeriksaan keselarasan jam memastikan kedua perangkat sepakat tentang waktu saat ini. Jika berbeda lebih dari 30 detik, sinkronisasi ditolak untuk mencegah korupsi timestamp.
Fase 2 — Push (Hub ke Spoke): Event klinis mengalir keluar. Hub mendorong snapshot penuh CIRS ke setiap Spoke setiap lima menit. Snapshot ini disimpan secara lokal di setiap Spoke — 12 salinan terbaru, jendela cadangan bergulir selama satu jam.
Fase 3 — Pull (Spoke ke Hub): Event sumber daya mengalir masuk: perubahan inventaris, operasi bank darah, catatan bedah, log dispensasi.
Enam Strategi Resolusi Konflik
| Strategi | Tipe data | Logika |
|---|---|---|
| Tambahkan keduanya | Tanda vital, serah terima, dispensasi | Event imutabel — simpan kedua versi |
| Terbaru menang | Demografi pasien | Bandingkan timestamp, pembaruan terbaru berlaku |
| Hub menang | Pendaftaran, resep, bedah | CIRS (Hub) bersifat otoritatif |
| Jumlahkan keduanya | Kuantitas inventaris | Jumlahkan konsumsi kedua sisi |
| Selalu blokir | Produk darah, zat terkontrol | Tidak pernah auto-resolve — memerlukan verifikasi manusia |
| Di tempat menang | Status peralatan | Operator yang hadir secara fisik diutamakan |
Jumlahkan keduanya untuk inventaris: Hub mengonsumsi 5 perban, Spoke mengonsumsi 3. Jawaban yang benar adalah 5 + 3 = 8 dikonsumsi.
Selalu blokir untuk produk darah: Unit darah yang ditandai "dikeluarkan" di kedua stasiun secara bersamaan tidak bisa diselesaikan oleh aturan otomatis manapun. Seseorang harus memverifikasi secara fisik di mana unit darah itu sebenarnya berada.
Cabut dan Jalan — Spoke Dipromosikan Menjadi Hub
Ini adalah kemampuan paling kuat dalam arsitektur.
Anda menjalankan deployment 1 Hub + 3 Spoke di insiden korban massal. Dua jam kemudian, komandan melaporkan titik pengumpulan korban kedua sepuluh kilometer jauhnya. Anda butuh stasiun medis yang berfungsi di sana sekarang.
Anda berjalan ke salah satu Spoke. Cabut kabel Ethernet. Masukkan ke tas dengan baterai dan iPad. Berkendara ke lokasi baru. Sambungkan daya. SSH dan jalankan satu perintah:
sudo xgrid-promote
Proses promosi adalah mesin state atomik. Jika langkah manapun gagal, seluruh operasi di-rollback — unit kembali ke mode Spoke.
Ketika berhasil, iPad terhubung ke jaringan WiFi baru, membuka PWA, dan Anda melihat stasiun medis yang sepenuhnya beroperasi dengan data pasien dari Hub asli — paling lama lima menit yang lalu.
Hub Down — Pengambilalihan dalam Lima Menit
Setiap Spoke terus memantau heartbeat Hub — setiap 30 detik. Tiga kegagalan berturut-turut (90 detik tanpa respons) memicu banner merah: "Hub offline."
Operator mengambil keputusan: Spoke mana yang mengambil alih? Script promosi memuat snapshot latest.good — symlink yang selalu menunjuk ke cadangan terverifikasi terbaru.
Kehilangan data pasien maksimum adalah lima menit — interval antara push snapshot.
Mengapa tidak mempromosikan secara otomatis? Karena di lingkungan terputus, Anda tidak bisa membedakan "Hub hancur" dari "kabel Ethernet longgar." Promosi otomatis berisiko menciptakan dua Hub yang keduanya merasa bertanggung jawab — kondisi split-brain. Promosi harus merupakan keputusan manusia.
Perlindungan Split-Brain — Epoch, Bukan Kepercayaan
Setiap kali Spoke dipromosikan menjadi Hub, penghitung epoch bertambah. Epoch tertanam di setiap snapshot, setiap broadcast mDNS, setiap handshake sinkronisasi.
Deteksi zombie. Hub A (epoch 1) crash dan Spoke B dipromosikan (epoch 2). Seseorang mencolokkan Hub A kembali. Saat startup, ia memindai jaringan dan menemukan Hub yang menyiarkan epoch 2 — lebih tinggi dari epoch 1 miliknya. Hub A otomatis menurunkan diri menjadi Spoke.
Validasi Spoke. Jika Spoke menemukan dua Hub dengan epoch berbeda, ia memunculkan peringatan oranye dan menolak auto-reconnect sampai manusia menyelesaikan ambiguitas.
Isolasi kluster. Setiap deployment membawa cluster_id unik. Spoke hanya menerima Hub dengan cluster_id yang cocok.
Penemuan Layanan — Tanpa IP Hardcode
xGrid menggunakan mDNS (multicast DNS) melalui avahi-daemon. Ketika Hub dimulai, ia menyiarkan _xgrid-hub._tcp di jaringan lokal. Spoke mendengarkan siaran ini. Ketika mendeteksi Hub baru dengan cluster ID valid dan epoch lebih tinggi, mereka memperbarui target koneksi secara otomatis.
Tidak perlu memperbarui file konfigurasi. Tidak perlu mengingat alamat IP. Jaringan mendeskripsikan dirinya sendiri.
Headless — iPad Anda Adalah Panel Kontrol
RPi xGrid tidak pernah memiliki monitor. Tidak pernah memiliki keyboard. Semua pekerjaan klinis terjadi melalui PWA di WiFi. Administrasi sistem melalui SSH.
Total hardware per stasiun: satu Raspberry Pi, satu kabel daya, satu kabel Ethernet (jika tidak mandiri). Jejak deployment cukup kecil untuk muat di ransel.
Konsolidasi Stasiun — Ketika Lokasi Dievakuasi
Empat mode penggabungan menangani skenario berbeda:
- Penggabungan penuh: Semua data mengalir ke stasiun tujuan
- Penggabungan parsial: Hanya kategori sumber daya terpilih yang ditransfer
- Import cadangan: Pulihkan dari cadangan portabel
- Penutupan darurat: Shutdown stasiun dengan preservasi data lengkap
Setiap penggabungan mencatat persis apa yang dipindahkan. Jejak audit ini menjawab pertanyaan yang selalu muncul setelah bencana: "Ketika stasiun itu dievakuasi, ke mana semuanya pergi?"
Mendesain untuk Ketidaktersambungan
Sebagian besar sistem terdistribusi dimulai dari premis "jaringan dapat diandalkan" dan menambahkan penanganan pengecualian untuk saat tidak.
xGrid dimulai dari premis "jaringan tidak dapat diandalkan" dan mengoptimalkan untuk saat kebetulan berfungsi.
Inversi ini menghasilkan desain yang secara fundamental berbeda:
- Setiap node adalah sistem lengkap (bukan thin client yang bergantung pada server)
- Setiap unit dikirim dengan semua software terinstal (peran adalah file konfigurasi)
- Spoke manapun bisa dipromosikan menjadi Hub
- Sinkronisasi adalah batch periodik (bukan streaming real-time)
- Resolusi konflik adalah perilaku default (bukan penanganan pengecualian)
- Hub usang menurunkan diri sendiri (karena epoch counter adalah fakta, bukan kebijakan)
Kabel akan tertendang. Switch akan jatuh dari meja. Hub akan terkena.
Tidak satu pun dari ini adalah mode kegagalan. Semuanya adalah transisi topologi.
Terkait: Offline-First Is Not a Fallback · ISBAR Is More Than a Handoff Format