Belajar Infrastructure Engineer - Data Infrastructure

#Pendahuluan

Setelah di episode 14 kita mengoperasikan platform Kubernetes, kini lapisan yang paling "berharga" dari infrastruktur: data. Database, cache, dan message broker adalah fondasi tempat aplikasi berdiri — dan lapisan yang paling sulit diskalakan serta paling menyakitkan saat bermasalah.

Mengapa topik ini penting? Karena data tidak bisa di-restart. Server boleh crash, pod boleh mati, tetapi database yang kehilangan data adalah bencana permanen. Episode ini membangun platform data dari sisi infrastruktur: managed database dan operasinya, Redis untuk cache, message broker untuk komunikasi antar layanan, dan praktik menjaga semuanya tetap sehat.

#Managed Database: Ops yang Didelegasikan

Di episode 2 kita membahas trade-off self-managed vs managed. Dalam praktik, managed database (RDS, Cloud SQL, Azure SQL) menghemat pekerjaan yang sangat besar:

Pola keputusan yang benar: database core bisnis dengan tim kecil → managed. Database dengan kebutuhan khusus (plugin, tuning ekstrem, versi tertentu) dan tim berpengalaman → self-managed. Keduanya bukan kalah-menang, melainkan soal di mana kalian mau menghabiskan tenaga.

#Operasi Dasar Managed DB

Koneksi aplikasi ke database selalu melalui connection string dengan kredensial yang dirotasi — bukan hardcode:

postgres://app_user:REDACTED@db-prod-1.ap-southeast-1.rds.amazonaws.com:5432/app

Latihan penting: uji failover — trigger failover terencana dan pastikan aplikasi tersambung kembali tanpa intervensi. Inilah perbedaan antara "kata vendor bisa failover" dan "bukti aplikasi tahan failover".

#Redis: Cache dan Lebih dari Itu

Redis adalah store in-memory serbaguna: cache, session store, rate limiter, pub/sub. Menempatkan Redis di depan database adalah cara paling efektif mengurangi beban database.

docker run -d --name redis -p 6379:6379 --restart unless-stopped redis:7
redis-cli -h localhost ping
redis-cli set cache:homepage "rendered-html" EX 300
redis-cli get cache:homepage

Pola cache yang benar:

1. Cache-read: aplikasi baca cache dulu, baru database jika miss.
2. TTL yang tepat: terlalu pendek = percuma; terlalu panjang = data basi.
3. Invalidation saat write: data berubah → cache di-update/hapus, jangan tunggu TTL.
4. Nama key yang konsisten: cache:homepage, cache:user:{id}.

#Redis Cluster dan HA

Untuk produksi: Redis Sentinel (failover otomatis) atau Redis Cluster (sharding + replika). Jangan menjalankan Redis single-instance untuk produksi — sebuah restart sudah bisa menurunkan seluruh aplikasi.

#Message Broker: Komunikasi Antar Layanan

Arsitektur modern (terutama microservice) memisahkan layanan melalui message broker — layanan tidak memanggil langsung, melainkan kirim pesan yang diproses asinkron.

Pola arsitektur yang wajib dipahami:

• Queue: satu pesan dikonsumsi satu consumer (RabbitMQ klasik).
• Topic/stream: satu pesan bisa dibaca banyak consumer (Kafka).
• At-least-once: consumer harus idempotent — pesan bisa diterima ulang.
• Dead letter queue: pesan yang gagal diproses berkali-kali dipindah untuk diperiksa manusia.

#Kafka sebagai Tulang Punggung Event

Kafka menyimpan event sebagai log yang bisa dibaca berulang (offset). Ini membuatnya cocok untuk event sourcing dan data pipeline:

kcat -b kafka-01:9092 -t orders -C -o beginning   # consume dari awal
kcat -b kafka-01:9092 -t orders -P                # produce event

Peran infra engineer: memastikan broker terdistribusi dan replikasi (replication factor ≥ 3), memantau lag consumer, dan menjaga kapasitas disk log.

#Menjaga Platform Data Sehat

#Monitoring Data Layer

Metrik yang wajib dipantau di semua komponen data:

Database:
  - Connection count & wait
  - Slow queries
  - Replication lag
  - Disk space & IOPS
Redis:
  - Hit ratio cache (target > 95%)
  - Memory usage (jangan penuh → eviction)
  - Connected clients
Kafka:
  - Consumer lag
  - Disk usage log
  - Under-replicated partitions

Alert replication lag dan consumer lag adalah dua alert yang paling sering menyelamatkan produksi.

#Backup Data Layer

Tingkatkan strategi backup dari episode 10 untuk lapisan data:

pg_basebackup -D /backup/base-$(date +%F) -Ft -z -P
# WAL archiving aktif → point-in-time recovery (PITR)

PITR (Point-in-Time Recovery) adalah kemampuan mengembalikan database ke waktu tertentu — menyelamatkan dari kesalahan manusia seperti DROP TABLE yang salah. Kombinasi: full backup berkala + WAL/redo log berkelanjutan.

#DR Data Layer

Pola DR untuk data (dari episode 10):

#Common Pitfalls Data Infrastructure

• Cache sebagai database: data yang tidak boleh hilang ditaruh di Redis — hilang diam-diam saat restart.
• Tanpa monitoring connection: pool database penuh = aplikasi "hang" tanpa alasan jelas.
• Idempotency diabaikan: consumer memproses ulang pesan dan menggandakan data.
• Kafka single-node: log event hilang = data analitik hilang.
• Query tanpa index: database melambat seiring data tumbuh — EXPLAIN adalah teman terbaik.
• Backup tidak pernah diuji restore — selalu, di semua layer (episode 10).

#Penutup

Pada episode 15 ini kalian telah membangun platform data:

• Managed database mendelegasikan backup/patch/HA; self-managed memberi kontrol — pilih berdasarkan tenaga tim.
• Redis mempercepat akses (cache, session) tetapi bukan tempat data kritis.
• Message broker (RabbitMQ/Kafka) menghubungkan layanan secara asinkron — pahami queue vs topic dan idempotency.
• Monitoring: replication lag, consumer lag, hit ratio cache adalah metrik penjaga produksi.
• PITR dan DR berlapis menjaga data dari kesalahan manusia hingga bencana.

Di episode 16 selanjutnya kita mendekatkan infrastruktur ke pengguna: edge & CDN — mempercepat distribusi global dengan content delivery dan edge compute. Sampai jumpa di episode 16!