Banyak aplikasi modern dirancang dengan asumsi yang naif: bahwa internet selalu stabil, cepat, dan tersedia setiap detik. Namun ketika kita turun langsung ke lapangan—seperti fasilitas logistik gudang berpendingin (*cold storage*), basement perkantoran, atau area perkebunan terpencil—asumsi tersebut seketika runtuh.

1. Masalah Lapangan: Kegagalan Paradigma "Cloud-First"

Saat mengembangkan Sesaat Segari untuk buruh harian lepas, saya menyaksikan bagaimana aplikasi berbasis server-first gagal total. Ketika seorang picker selesai membongkar palet buah pada pukul 03.00 dini hari di dalam ruangan bersuhu -5°C dengan dinding panel baja peredam sinyal seluler, request HTTP ke server akan mengalami timeout. Akibatnya, jam lembur pekerja tidak tercatat, dan hak upah mereka terpotong.

Prinsip Inti Offline-First: Penyimpanan lokal (*local database*) bukanlah sekadar cache sementara. Database lokal adalah sumber kebenaran primer (*Primary Source of Truth*) untuk seluruh operasi pengguna. Layar aplikasi harus selalu bisa membaca dan menulis data seketika dalam hitungan milidetik tanpa menunggu handshake jaringan.

2. Skema SQLite Lokal & Audit Trail

Untuk menjamin bahwa data presensi dan lembur tidak dapat dimanipulasi atau hilang saat aplikasi ditutup paksa (*force close*), kita merancang tabel SQLite dengan *audit trail* yang ketat:

CREATE TABLE shift_records ( id TEXT PRIMARY KEY, worker_id TEXT NOT NULL, clock_in_time INTEGER NOT NULL, -- Unix Timestamp (ms) clock_out_time INTEGER, tolerance_minutes INTEGER DEFAULT 5, penalty_deduction REAL DEFAULT 0.0, calculated_wage REAL NOT NULL, sync_status TEXT DEFAULT 'PENDING', -- 'PENDING', 'SYNCED', 'CONFLICT' device_created_at INTEGER NOT NULL, integrity_checksum TEXT NOT NULL -- SHA-256 (id + worker_id + clock_in) ); CREATE INDEX idx_worker_sync ON shift_records (worker_id, sync_status);

3. Strategi Conflict Resolution: Queue Mutasi & Idempotensi

Tantangan terbesar sistem offline-first terjadi saat koneksi internet kembali pulih (*reconnection*). Jika pengguna melakukan mutasi data secara offline di dua sesi berbeda, bagaimana server menentukan versi mana yang sah?

  • Client-Side Outbox Queue: Seluruh aksi mutasi (INSERT/UPDATE) disimpan dalam antrean antarmuka terenkripsi lokal.
  • Idempotent API Endpoints: Setiap mutasi dikirim dengan UUID unik. Jika request terkirim berulang akibat *network retry*, server tidak akan membuat entri ganda.
  • Deterministic Merge: Untuk data presensi, timestamp lokal bersertifikat kriptografi dijadikan dasar kalkulasi penalti yang adil bagi pekerja.

4. Hasil Terukur & Pelajaran Berharga

Dengan arsitektur offline-first ini, Sesaat Segari berhasil mencapai 100% ketersediaan operasional (*zero-downtime*). Bahkan ketika gudang mengalami pemadaman BTS provider, pekerja tetap dapat melihat estimasi upah harian secara presisi, mencetak slip format PDF terenkripsi, dan mengekspornya langsung via Bluetooth atau WhatsApp saat sinyal kembali hadir.