Belajar Solution Architect - Data Solution Design

#Pendahuluan

Setelah di episode 6 solusi kalian bisa "berbicara" dengan sistem lain lewat integrasi sinkron/asinkron yang idempotent, sekarang kita bahas komponen yang paling sering menentukan umur sebuah solusi: datanya sendiri. Aplikasi bisa ditulis ulang dalam beberapa bulan; keputusan data yang salah akan menghantui bertahun-tahun — karena migrasi data besar itu mahal, lambat, dan berisiko.

Mengapa ini penting bagi SA? Karena pertanyaan "data ini disimpan apa?" hampir selalu punya jawaban salah jika ditanyakan terlambat. Tim development cenderung menjawab cepat dengan "PostgreSQL semua" atau sebaliknya "pakai NoSQL biar keren". Tugas kalian mencocokkan pola akses dengan karakteristik storage — bukan selera.

#Memilih Storage Berdasarkan Pola Akses

Empat keluarga besar yang wajib kalian kuasai:

Prosedur pemilihan yang disiplin: tulis dulu pola akses dalam kalimat konkret — "cari order berdasarkan ID", "daftar event terdekat per kota", "total penjualan per bulan 3 tahun terakhir" — baru cocokkan. Kalimat pola akses itulah yang menentukan, bukan nama teknologi yang sedang tren.

#Studi Kasus Tiket: Pemetaan Data

Terapkan pada studi kasus kita:

Orders & payments   -> PostgreSQL (ACID: uang tidak boleh setengah jadi)
Seat map live       -> Redis      (baca/tulis super cepat, TTL lock 10 menit)
Gambar poster event -> Object storage + CDN (murah, statis)
Riwayat & analitik  -> Warehouse  (agregasi penjualan, tanpa ganggu OLTP)
Log pemindaian QR   -> NoSQL document (volume tinggi, tulis-append)

Perhatikan bahwa satu solusi memakai empat jenis storage — itu normal dan sehat. Yang tidak sehat adalah memaksakan satu database melayani workload transaksional sekaligus analitik berat, lalu heran kenapa checkout ikut lambat tiap kali tim finance tarik laporan bulanan.

#Arsitektur Data Platform End-to-End

Ketika kebutuhan analitik tumbuh, pola arsitekturnya berkembang menjadi platform data. Bentuk klasiknya:

Tiga zona yang lazim di data lake modern:

1. Raw — data mentah persis seperti sumbernya, immutable. Kalau transformasi salah, raw masih utuh untuk diproses ulang.
2. Modeled/curated — data sudah dibersihkan, dinormalisasi/denormalisasi sesuai kebutuhan bisnis, dengan definisi metrik tunggal ("revenue" artinya apa? harus ada satu jawaban).
3. Serving — lapisan konsumsi: dashboard BI, API metrik, feature store untuk ML.

Prinsip penting: OLTP dan analitik dipisahkan. CDC (change data capture, misal Debezium atau logical replication) menyalin perubahan dari database operasional ke pipeline tanpa memberatkan production.

#Caching sebagai Bagian Desain Data

Cache sering diperlakukan sebagai tambalan performa belakangan — padahal desain cache yang benar harus dipikirkan bersama data model:

• Apa yang di-cache: data baca-intensif dan toleran terhadap kemunduran singkat (stale beberapa detik): seat map publik, daftar event, profil.
• Yang jangan di-cache: saldo, status pembayaran — kecuali invalidasi-nya dirancang ketat.
• Strategi umum: cache-aside (app cek cache → miss → baca DB → isi cache) paling aman; write-through untuk data yang harus selalu hangat; TTL sebagai jaring pengaman invalidasi.
• Hitung hit ratio target: naikkan dari 0% ke 90% biasanya menurunkan beban DB puluhan kali lipat — angka yang layak masuk SDD bagian estimasi kapasitas.

#Modeling yang Bertahan Saat Membesar

Beberapa praktik modeling yang menyelamatkan kalian nanti:

• Normalisasi untuk OLTP, denormalisasi sadar untuk read-heavy — duplikasi terkontrol (misal snapshot harga di tabel order item) demi query cepat dan audit historis.
• Immutable events untuk hal sensitif uang: jangan update baris pembayaran; catat kejadian berturut (created → paid → refunded). Audit trail gratis.
• Soft delete + retention policy di level skema: siapa yang boleh menghapus apa, berapa lama data PII disimpan (nyambung ke compliance episode 19).
• Partitioning sejak terencana: tabel log/pemindaian QR dipartisi per bulan supaya retention (drop partisi tua) murah, tanpa DELETE masif.
• Data model = kontrak juga: kolom yang dihapus dari skema produksi sama berbahayanya dengan endpoint API yang dicabut — versikan migration dan jaga backward compatibility selama deploy rolling berlangsung.

Untuk warehouse modern, teknik ELT mendominasi: muat mentah dulu ke raw zone, transformasi dengan SQL ter-versioned (dbt misalnya), sehingga transformasi bisa dites dan direplay. Ini kebalikan ETL klasik dan lebih cocok dengan prinsip raw-immutable di atas.

#Common Pitfalls

• Database sebagai integration bus — dua aplikasi saling membaca tabel internal satu sama lain. Setiap perubahan skema merobek pihak lain. Mitigasi: integrasi via API/event (episode 6), bukan via tabel langsung.
• N+1 dan query tanpa index di jalur panas — masalah klasik yang muncul di load test, bukan di laptop dev. Mitigasi: pola akses utama wajib punya EXPLAIN plan yang direview.
• Warehouse dipakai untuk OLTP — BigQuery hebat untuk agregasi, tapi insert/update baris-per-baris transaksional bukan wilayahnya.
• Backup belum pernah di-restorasi — backup yang tidak pernah diuji restore sama dengan tidak punya backup (kita formalisasikan di episode 15).
• PII tersebar tak terkendali — kolom email/NIK tersalin ke lima sistem tanpa pencatatan. Mulai sekarang: daftar data sensitif + lokasinya, fondasi compliance nanti.

#Penutup

Inti yang harus dibawa pulang:

• Pilih storage dari pola akses, bukan tren: relational untuk transaksi, key-value untuk latensi rendah, warehouse untuk analitik, object storage untuk file dan raw data.
• Satu solusi boleh dan sering memakai beberapa jenis storage sekaligus.
• Pisahkan OLTP dari analitik; gunakan CDC agar beban production tidak terganggu pipeline reporting.
• Cache adalah bagian desain data: tentukan apa yang boleh stale dan bagaimana invalidasinya.
• Modeling sadar masa depan: immutable events untuk uang, partitioning untuk retention, skema sebagai kontrak.

Di episode 8 selanjutnya kita akan membahas security solution design — menyuntikkan security ke dalam solusi sejak awal: threat model ringkas, enkripsi in transit/at rest, manajemen secret, identity untuk manusia maupun service, dan bagaimana compliance mempengaruhi pilihan desain. Sampai jumpa di episode 8!