Offline-First untuk Aplikasi Tim Lapangan: Desain untuk Sinyal Seadanya

Offline-First untuk Aplikasi Tim Lapangan: Desain untuk Sinyal Seadanya

Statistik nasional bilang internet Indonesia baik-baik saja: 212 juta pengguna, penetrasi 74,6% per Januari 2025, dan 96,4% koneksi mobile sudah 3G/4G/5G dengan kecepatan unduh median 29,06 Mbps. Tapi statistik itu tidak pernah turun ke ruang utilitas di basement. Bagi teknisi yang berdiri di antara beton dan besi tulangan, atau di lantai smelter yang dikelilingi enclosure logam, sinyal satu bar saja sudah rezeki.

Setiap aplikasi field-service yang saya bangun untuk utility metering dan facility work berangkat dari premis yang sama: offline bukan kasus khusus. Offline itu kondisi default, dan harus dirancang begitu sejak hari pertama.

Arsitektur: queue lokal sebagai source of truth

Bayangkan teknisi seperti kurir: paket dicatat di buku catatannya sendiri dulu, lapor ke kantor pusat belakangan. Dia tidak berhenti kerja cuma karena tidak bisa menghubungi kantor. Polanya gampang dijelaskan — dan gampang juga salah diterapkan.

Semua aksi teknisi — pembacaan meter, foto, work order yang selesai — ditulis ke storage di device lebih dulu, tanpa kecuali. Sync ke server berjalan belakangan sebagai background job, begitu ada sinyal. Tidak ada satu pun langkah kerja teknisi yang harus menunggu koneksi.

Ini ide yang sama dengan yang ditulis Martin Kleppmann dan tim Ink & Switch dalam esai local-first software mereka: salinan utama data ada di device, dan pengguna selalu bisa membaca serta menulisnya. Sinkronisasi dengan salinan lain menyusul, bukan jadi syarat untuk bisa bekerja. PouchDB dan CouchDB sudah menjalankan model ini bertahun-tahun di production — tulis lokal, replikasi begitu ada kesempatan.

Bangun UI di atas queue lokal, bukan di atas respons network. Teknisi melihat pembacaannya tersimpan, lalu lanjut ke aset berikutnya — sinyal penuh atau nol bar, sama saja.

Aturan konflik yang beneran diterima tim operasional

Dua teknisi bisa saja memegang aset yang sama selagi dua-duanya offline. Satu memeriksa meter pagi hari; satu lagi datang sore, sebelum kedua device sempat sync. Last-write-wins yang naif akan membuang salah satu pembacaan itu diam-diam. Tidak ada yang sadar — sampai ada sengketa tagihan, dan angka yang dipersoalkan ternyata tidak pernah ada.

CRDT penuh — struktur data yang bisa digabung otomatis tanpa konflik — bisa menyelesaikan ini dengan benar, tapi untuk form metering atau tiket, itu alat yang kebesaran. Model datanya cuma beberapa field, bukan dokumen yang diedit bersama — overhead engineering tipe data conflict-free general-purpose tidak sepadan.

Jalan tengah yang bisa diterima tim operasional punya dua aturan. Pertama, field hasil capture — pembacaan itu sendiri, timestamp, foto — berstatus field-of-record: device mana pun yang menangkapnya, nilainya tidak pernah diam-diam ditimpa submission lain. Kedua, kalau concurrent edit benar-benar terjadi — dua teknisi menutup work order yang sama dengan catatan berbeda — konfliknya ditandai untuk direview manusia, bukan di-merge otomatis. Tim ops lebih percaya sistem yang bilang "dua hal ini konflik, pilih salah satu" dibanding sistem yang diam-diam menebak di belakang layar.

Ingestion server yang idempotent

Sinyal yang tidak stabil bukan cuma bikin device offline, tapi juga memicu retry storm. Teknisi submit pembacaan, koneksi putus di tengah request, aplikasi timeout lalu submit ulang. Server pun menerima pembacaan yang sama dua kali, tanpa bisa tahu keduanya event yang sama.

Solusinya idempotency key yang dibuat client, melekat ke setiap submission dan terikat ke event capture itu sendiri, bukan ke request-nya. Pola idempotency-key Stripe jadi model rujukannya. Server menyimpan hasil request pertama untuk key itu, lalu membalas retry mana pun yang membawa key sama dengan respons identik.

Terapkan aturan yang sama ke submission pembacaan meter atau work order. Retry storm akibat sinyal buruk jadi tidak berbahaya — resubmission kesepuluh dari pembacaan yang sama adalah no-op, bukan baris duplikat.

Yang harus diuji sebelum rollout

Sebagian besar hal yang bikin rollout aplikasi lapangan gagal baru kelihatan saat dipakai sungguhan. Uji dulu dengan sengaja:

• Drill airplane-mode seharian — teknisi bekerja satu shift penuh dengan konektivitas mati, lalu tersambung kembali.
• Drift jam device — timestamp yang dibuat offline di device yang jamnya meleset, dan efeknya ke aturan konflik.
• Queue overflow — apa yang terjadi ke queue lokal setelah seminggu offline tanpa sync sama sekali. Apakah entri terlama dibuang, entri baru ditolak, atau disk-nya penuh begitu saja?
• Dua teknisi, satu aset — concurrent edit dari device terpisah yang belum saling sync.
• Sync terputus — koneksi yang putus di tengah upload, terutama saat ada foto bukti yang menyertai.
• Retry storm saat reconnect — device yang mengantre retry yang sama belasan kali semalaman, lalu semuanya terkirim serentak begitu sinyal kembali.

Kalau salah satu dari ini menghasilkan pembacaan meter duplikat, foto yang hilang, atau field yang diam-diam tertimpa, itu blocker rollout. Bukan bug yang dicatat untuk nanti.

Menerapkannya ke utility metering dan facility work

Di sinilah pola ini paling terasa gunanya. Pembacaan meter dan foto inspeksi dari basement dan lantai pabrik justru jenis bukti yang paling sering dipersoalkan belakangan: pelanggan mempertanyakan tagihan, auditor minta bukti pemeriksaan fasilitas.

Dengan queue local-first, bukti itu tersimpan sejak detik diambil — lengkap dengan timestamp dan identitas device teknisi — kapan pun bukti itu akhirnya sampai ke server. Dan karena kunjungan beberapa teknisi ke aset yang sama itu rutin di facility work, aturan field-of-record dan review manual justru paling penting di kategori aplikasi ini.

Satu hal lagi yang konsisten disampaikan tim operasional ke saya: mereka ingin melihat isi queue itu sendiri. Layar yang menampilkan "14 pembacaan menunggu sync" membangun kepercayaan lebih besar dibanding aplikasi yang menyembunyikan mekanismenya dan cuma berharap sinyal kembali. Teknisi dan supervisor sama-sama membuat keputusan lebih baik saat status sync terlihat, bukan sekadar diasumsikan.

Checklist rollout: pertanyaan untuk vendor atau tim developer

Sebelum menyetujui aplikasi lapangan, tanyakan langsung:

1. Apa source of truth saat device offline — storage lokal, atau aplikasinya cuma jadi read-only?
2. Apa aturan konflik untuk capture field versus concurrent edit, dalam bahasa yang jelas, bukan sekadar "kami tangani otomatis"?
3. Mekanisme idempotency apa yang mencegah retry storm membuat record duplikat di server?
4. Berapa kapasitas queue-nya, dan apa yang terjadi kalau terlampaui?
5. Apakah aplikasinya sudah benar-benar diuji offline seharian penuh, bukan cuma demo dengan wifi dimatikan lima menit?

Kalau vendor tidak bisa menjawab pertanyaan ketiga dan keempat dengan spesifik, lapisan sync-nya belum dirancang. Itu cuma diasumsikan.

Di sisi backend, disiplin ingestion yang sama berlaku: penulisan idempotent, data ternormalisasi yang mendarat di satu server of record. Ini masalah yang sama yang saya bahas di panduan lengkap backend IoT — bedanya, datanya datang dari client mobile yang mengantre, bukan dari stream device yang live.