Belajar IoT Engineer - Large-Scale IoT Architecture

#Pendahuluan

Semua praktik kita sejauh ini masuk akal untuk puluhan hingga ribuan perangkat. Episode ini menjawab pertanyaan: apa yang berubah ketika skala menjadi jutaan? Arsitektur yang "cukup baik" untuk 1.000 perangkat bisa runtuh di 1.000.000.

Mengapa skalabilitas harus dipikirkan sejak awal? Karena biaya untuk memigrasi arsitektur setelah jutaan perangkat terhubung sangat besar — perangkat di lapangan tidak bisa di-update semudah server. Keputusan desain seperti naming topik, skema data, dan protocol tidak bisa diubah tanpa operasi masif. Pikirkan skala dari hari pertama, walaupun kalian mulai dari 10 perangkat.

#Apa yang Pecah Saat Skala Membesar

Perubahan yang paling terasa: data dan biaya. Sejuta perangkat mengirim 1 pesan/menit = 1,44 miliar pesan/hari. Setiap keputusan di pipeline berdampak jutaan kali lipat.

#Pola Horizontal Scaling

Arsitektur skala besar memakai horizontal scaling — menambah node, bukan memperbesar satu node.

         ┌─ broker-1 ─┐
devices ─┤─ broker-2 ─┼── queue/stream ─┬─ consumer-a
         └─ broker-3 ─┘                 └─ consumer-b

Prinsip kuncinya:

• Stateless components — setiap komponen tidak menyimpan state lokal yang mengikat; bisa dipecah berkali-kali.
• Buffer di antara — selalu ada queue/streaming antara ingestor dan storage agar lonjakan tidak menjatuhkan hilir (episode 8).
• Auto-scaling consumer — jumlah consumer naik-turun mengikuti volume data.
• Partisi data — pecah data per region/perangkat untuk isolasi kegagalan.

#Partisi dan Backpressure

Partisi membagi beban agar tidak satu titik menampung semua. Contoh pada pipeline:

• Partisi per region: data jakarta dan surabaya di partisi terpisah.
• Partisi per device_id: hash device ke partisi; consumer bisa membaca per kelompok.
• Shard storage: time series DB di-shard berdasarkan rentang waktu.

Backpressure memastikan sistem tetap hidup saat hilir melambat: producer memperlambat (atau buffer menumpuk sementara) alih-alih membanjiri storage. Tanpa backpressure, satu perlambatan InfluxDB membuat ribuan pesan menumpuk lalu hilang.

Ingestor → queue (bisa menumpuk sementara) → consumer (batch)
                ↑ jika storage lambat, queue menyerap

#Kontrol Biaya: Cost Engineering

Biaya adalah constraint desain di skala besar — bukan masalah "nanti". Teknik yang paling berdampak:

Contoh perhitungan: 1 juta perangkat × 1 pesan/menit × 100 byte = ±12 GB/jam sebelum penghematan. Dengan agregasi per menit di edge dan downsampling, bisa turun 90%+ biaya storage.

#Praktik: Keputusan Desain untuk Skala Besar

Studi kasus: platform monitoring kota pintar dengan 500.000 sensor lingkungan. Keputusan desainnya:

500K sensor → gateway kota → EMQX cluster (3 node)
    → Kafka (buffer, 3 partisi per region)
    → consumer (downsampling + validasi)
    → Tiered storage: InfluxDB hot (7 hari) → S3 cold (arsip)
    → Grafana + alerting + analitik

Keputusan yang mendasari:

1. Broker cluster, bukan 1 broker — failover dan kapasitas koneksi.
2. Kafka sebagai buffer universal — isolasi lonjakan, multi-consumer.
3. Downsampling di consumer — data 1 menit hanya 7 hari; lalu 1 jam untuk 90 hari.
4. Cold storage murah — kepatuhan/episode 20 butuh arsip, tapi tidak butuh akses cepat.
5. Alerting berbasis event — dashboard tidak perlu query semua data.

#Kesalahan Umum

1. Optimasi dini untuk skala yang belum ada — biaya dan kompleksitas membengkak tanpa manfaat; scaling bertahap.
2. Semua data disimpan selamanya di hot storage — biaya storage memakan margin.
3. Tanpa buffer — lonjakan data mematikan storage.
4. Satu endpoint/broker tunggal — single point of failure di skala besar.
5. Cost tidak dimonitor per fitur — tidak tahu fitur mana yang paling mahal.
6. Desain tidak bisa diubah — topik/skema kaku; pikirkan evolusi sejak awal.

#Penutup

Inti yang harus dibawa pulang:

• Skala besar mengubah segalanya: koneksi, data, biaya, debugging, update.
• Scaling horizontal + stateless + buffer + auto-scaling + partisi.
• Backpressure melindungi hilir dari lonjakan.
• Cost engineering adalah constraint desain: batch, downsampling, tiering, edge.
• Pikirkan skala sejak hari pertama — karena perangkat di lapangan tidak mudah di-update.

Di episode 22 selanjutnya, kita akan membangun representasi digital dunia fisik: digital twin & simulation — apa itu digital twin, bagaimana ia membantu simulasi dan prediksi, serta praktik membangun twin sederhana dari perangkat kalian. Dunia fisik akan punya "cermin digital"!