Belajar Solution Architect - Edge & IoT Solutions

#Pendahuluan

Setelah di episode 22 kalian bisa merancang platform analitik dari ingestion sampai governance metrik, episode ini membawa kita ke tempat data lahir paling ujung: perangkat di lapangan. Sensor gudang, mesin produksi, POS cabang toko, armada kendaraan — semuanya menghasilkan data yang bernilai, dengan dua tantangan arsitektur unik: konektivitas yang tak bisa diandalkan, dan jumlah perangkat yang dihitung ribuan bukan puluhan.

Mengapa edge/IoT menantang bagi SA? Karena pola cloud klasik "semua ke cloud" sering gagal di sini: bandwidth mahal untuk video sensor, latensi 200 ms tak cukup untuk kontrol mesin, dan internet cabang yang mati sejam tidak boleh menghentikan operasional toko. Solusinya adalah memindahkan sebagian logika mendekati sumber data — dengan semua konsekuensi desainnya.

#Kapan Edge Layak: Spektrum Cloud-Edge

Keputusan pertama adalah di mana komputasi berjalan. Spektrumnya:

Edge layak ketika salah satu terpenuhi:

1. Latensi — kontrol aktuator atau inferensi vision butuh respons <50 ms; round-trip cloud mustahil.
2. Bandwidth/biaya egress — 100 kamera streaming mentah 24/7 ke cloud = tagihan bunuh diri; filter/deteksi di edge kirim hanya event.
3. Ketersediaan offline-first — cabang dengan internet flaky tetap harus bisa transaksi.
4. Souverenitas/privasi — footage wajib diproses lokal, hanya metadata naik.

Jika tidak ada yang terpenuhi, jawabannya tetap cloud penuh — edge menambah permukaan maintenance yang nyata (ribuan kotak fisik harus di-update bertahun-tahun).

#Topologi Referensi Edge-IoT

Bentuk arsitektur yang paling sering saya pakai sebagai titik awal:

Tiga prinsip yang membuat topologi ini tahan banting:

• Gateway adalah buffer cerdas: menyimpan telemetri saat link mati (store-and-forward), memfilter duplikat/noise, dan menjalankan logika darurat lokal (tutup valve jika tekanan anomali — tanpa menunggu cloud).
• Komunikasi dua arah asimetris: upstream = event bernilai (terfilter); downstream = konfigurasi, aturan, firmware. Downstream jarang tapi kritikal — jalurnya harus andal dan diaudit.
• Cloud adalah sumber kebenaran: fleet state (versi firmware, konfigurasi, health) dicatat di cloud; edge boleh otonom sementara, tapi harus reconverge.

#Protokol Telemetri: MQTT dan Sahabatnya

Pilihan protokol menentukan daya tahan sistem di jaringan buruk:

MQTT menjadi standar de facto karena fitur-fiturnya persis menjawab masalah lapangan:

• QoS levels: 0 (fire-and-forget), 1 (at-least-once, standar untuk data penting), 2 (exactly-once, lebih berat). Konsekuensi QoS 1 sama dengan episode 6: consumer wajib idempotent.
• Persistent session + retained message — device yang reconnect mendapat pesan yang terlewat dan konfigurasi terakhir tanpa mekanisme custom.
• Topic hierarchy — desain topic dengan disiplin namespace: site/{site_id}/device/{device_id}/telemetry. Topic yang rapi = otorisasi granular dan routing analytics mudah.

Contoh payload telemetri yang disiplin (ringkas, timestamped, versioned):

{
  "schema": "telemetry.temp.v2",
  "ts": "2026-08-16T09:30:00+07:00",
  "site_id": "wh-jkt-01",
  "device_id": "sensor-a3f9",
  "celsius": 4.2,
  "battery_pct": 87,
  "flags": ["door_open"]
}

Kolom schema dengan versi adalah data contract mini (episode 6 dan 22): armada perangkat akan hidup lebih lama dari skema pertama kalian.

#Offline-First: Merancang untuk Internet yang Mati

Asumsi dasar edge design: konektivitas adalah kemewahan, bukan kebutuhan operasional. Pola-pola intinya:

• Local transaction processing — POS cabang mencatat transaksi ke local store (SQLite/level DB) dan sinkronisasi belakangan; kasir tetap jalan saat internet mati.
• Conflict resolution eksplisit — saat dua sisi mengubah data sama selama offline, siapa menang? Pilihan umum: last-write-wins untuk data non-kritis, CRDT/merge rules untuk inventory, dan antrian approval manual untuk konflik uang. Keputusan ini harus tertulis sebelum deployment, bukan saat insiden pertama.
• Buffer dengan batas — local store punya kapasitas; hitung worst-case offline duration × data rate, dan definisikan perilaku saat penuh (drop oldest? prioritas alarm?).
• Clock discipline — device tanpa NTC/NTP melenceng waktu; gunakan timestamp server saat sinkronisasi plus monotonic ordering lokal. Data dengan jam kacau meracuni analitik downstream (episode 22).

#Fleet Management: Ribuan Perangkat Selama Bertahun-Tahun

Perangkat IoT bukan server yang bisa kalian SSH kapan saja — ia tersebar, kadang di lokasi tanpa akses fisik. Manajemen armada adalah separuh dari solusi:

#Provisioning & Identity

• Setiap device punya identitas kriptografis unik (certificate per device) yang dibakar saat manufaktur/provisioning — bukan shared password firmware (yang bocor sekali = bocor semua).
• Zero-touch provisioning: device baru otomatis mendaftar, menerima konfigurasi awal dan certificate via bootstrap service.

#Update OTA yang Aman

Update firmware jarak jauh adalah fitur paling berisiko sekaligus paling wajib:

1. Signed image — device hanya menerima update bertanda tangan kalian; channel OTA yang dibajak tak bisa menanam kode.
2. Staged rollout — canary 1% → 10% → 100%, dengan health check antar gelombang dan auto-halt saat metrik buruk (pola rilis yang sama dengan deployment aplikasi).
3. Rollback mandiri — dual partition A/B: update ditulis ke partisi idle, boot gagal = otomatis kembali ke partisi lama. Device "brick" di lokasi terpencil adalah biaya servis fisik termahal.
4. Window & throttling — update diterapkan di jam sepi lokasi, dikontrol rate agar tidak membanjiri broker.

#Observability Armada

Metrik tingkat armada yang dipantau di cloud: persentase device online, versi firmware distribution, battery health, error rate per model device, dan lag sinkronisasi per site. Dashboard armada inilah yang menjawab "kenapa data gudang Surabaya kosong sejak Senin?" dalam menit, bukan minggu.

#Security di Ujung Jaringan

Melanjutkan defense in depth episode 18 dengan konteks device:

• Network segmentation — device/IoT di VLAN sendiri, tidak boleh bicara langsung ke sistem korporat cabang.
• Least privilege per device — certificate device X hanya boleh publish ke topiknya sendiri; broker meng-enforce ACL.
• Physical assumption — device bisa direbut fisiknya: simpan secret minimal di device, key di secure element bila tersedia, dan rencanakan revokation per device (sertifikat pendek umur).
• Telemetry integrity — untuk data yang memicu keputusan regulasi/pembayaran, tambahkan signing payload agar manipulasi terdeteksi.

#Penutup

Inti yang harus dibawa pulang:

• Edge layak hanya atas alasan konkret: latensi, bandwidth/egress, offline-first, atau souverenitas — bukan mode.
• Topologi referensi: gateway buffer cerdas di lapangan, komunikasi MQTT dua arah yang asimetris, cloud sebagai source of truth armada.
• MQTT + QoS 1 memberi ketahanan jaringan; konsekuensinya idempotency di consumer, dan topic hierarchy dirancang seperti API contract.
• Offline-first diuji dengan kabel ditarik, conflict resolution ditentukan sejak desain, dan buffer/clock disiplin dihitung.
• Fleet management setara pentingnya dengan aplikasi: identity per device, signed OTA staged dengan rollback A/B, observability armada.

Di episode 24 selanjutnya kita akan membahas solution architecture review — cara mengevaluasi solusi secara sistematis: rubrik review lintas dimensi, fitness functions yang bisa diukur otomatis, menjalankan sesi review yang produktif, dan mengubah temuan menjadi keputusan yang dieksekusi. Sampai jumpa di episode 24!