Belajar Software Architect - Data Architecture

#Pendahuluan

Setelah di episode 7 kita mendesain modul dengan boundary tegas — zona publik eksplisit, larangan akses tabel lintas modul, dan fitness function penjaganya — pada episode ini kita garap sisi yang paling sering menentukan umur panjang sebuah arsitektur: data.

Mengapa data begitu menentukan? Karena skema data adalah komponen paling mahal diubah. Kode bisa di-refactor dalam hitungan hari; data yang salah model harus dimigrasi bertahun-tahun sambil sistem tetap berjalan. Dan begitu data tersebar ke banyak penyimpanan (yang hampir pasti terjadi), pertanyaan konsistensi menjadi pusat seluruh desain.

#Tiga Level Pemodelan Data

Pemodelan data bekerja di tiga level abstraksi — dan architect utamanya tinggal di dua level pertama:

1. Conceptual — entitas bisnis dan relasinya, tanpa teknologi. Customer melakukan Order yang berisi Product. Bahasa bounded context dari episode 4 hidup di sini.
2. Logical — struktur formal: tabel/koleksi, kunci, kardinalitas, normalisasi. Belum menyentuh produk spesifik.
3. Physical — implementasi nyata: index, partitioning, tipe kolom, engine tertentu.

Kesalahan klasik tim: melompat langsung dari requirement ke physical ("buatkan tabelnya") sehingga keputusan struktural terselubung di dalam DDL. Kebiasaan sehat: gambar conceptual bersama stakeholder, validasi logical bersama senior engineer, baru delegasikan physical.

#Polyglot Persistence: SQL vs NoSQL per Use Case

Tidak ada satu database untuk semua kebutuhan — pilih per pola akses:

Prinsip penggunaannya disiplin: setiap tambahan datastore adalah biaya operasional permanen (backup, monitoring, keamanan, keterampilan tim). Polyglot bukan lisensi menumpuk teknologi; ia jawaban untuk kebutuhan akses yang benar-benar berbeda.

#Spektrum Konsistensi

Konsistensi bukan saklar on/off, melainkan spektrum:

Strong          Read-your-writes   Eventual
(ACID lokal)    (session sticky)   (lag replikasi terlihat)
     ▲                                        ▲
  payment, stok                          feed, rekomendasi,
  checkout                               notifikasi, analitik

Dua kerangka teori di baliknya cukup dipahami secara intuisi:

• CAP — saat partisi jaringan terjadi, pilih consistency (tolak request) atau availability (terima risiko stale). Partisi pasti terjadi, jadi pertanyaannya bukan "mau CAP mana", tapi "saat partisi, apa prioritasnya".
• PACELC — melengkapi CAP bahkan tanpa partisi: latency vs consistency tetap trade-off sehari-hari. Replikasi sinkron = latensi naik; async = risiko stale.

Keputusan praktisnya per-aliran-data, bukan per-sistem: jalur checkout studi kasus kita butuh strong consistency untuk stok dan pembayaran; feed aktivitas dan email marketing nyaman eventual.

#Kepemilikan Data Antar Modul

Aturan kepemilikan turun langsung dari boundary modul episode 7:

• Satu modul memiliki datanya — hanya modul ordering boleh menulis tabel orders. Modul lain membaca via API publik atau event.
• Duplikasi itu wajib, bukan dosa — catalog module membutuhkan nama produk saat menampilkan order. Jangan query tabel catalog; simpan snapshot nama produk di order (denormalisasi sadar). Nama produk berubah tidak boleh mengubah histori transaksi.
• Integrasi via event — ketika inventory berubah, ia memancarkan event StockChanged; siapa pun yang butuh salinan, update salinannya sendiri.

Di sinilah outbox pattern masuk. Masalah klasik: modul menulis database lalu menerbitkan event ke broker — dua langkah yang bisa gagal terpisah (sukses commit, gagal publish, atau sebaliknya). Solusinya:

1. Dalam SATU transaksi DB:
   tulis data bisnis + tulis event ke tabel outbox
2. Relay proses baca outbox → publish ke broker → tandai terkirim
3. Consumer idempotent (event bisa terkirim lebih dari sekali)

Transaksi lokal menjamin data dan event sama-sama ada atau sama-sama tidak; relay menambah at-most-sekali-jeda, consumer menangani duplikasi. Pola ini akan kita pakai eksplisit di saga episode 12 dan Kafka episode 13.

#CQRS: Pisahkan Jalur Baca dan Tulis

Command Query Responsibility Segregation memisahkan model tulis (dinormalisasi, menjaga invariant) dari model baca (didenormalisasi, dioptimalkan query). Sinkronisasi keduanya lewat event — final consistency.

Kapan layak:

• Read path jauh lebih berat daripada write (rasio 100:1 umum di e-commerce).
• Query baca bentuknya sangat berbeda dari struktur tulis (laporan agregat, pencarian).
• Kebutuhan scale selektif: replika baca atau search index tanpa menyentuh jalur tulis.

Kapan berlebihan: CRUD sederhana dengan traffic seimbang — CQRS di sana hanya menambah dua model untuk dirawat tanpa manfaat terukur.

#Praktik: Desain Data Studi Kasus E-commerce

Mari terapkan. Peta kepemilikan data:

postgreSQL:            # satu cluster, schema per modul
  catalog_schema:      products, categories
  ordering_schema:     orders, order_items, outbox
  inventory_schema:    stock_items, reservations
  payment_schema:      charges, refunds
redis:                 cache & session
elasticsearch:         indeks produk (baca katalog)
kafka:                 topik event antar modul (via outbox)

Alur kritis checkout dengan konsistensi yang tepat per bagian:

1. reserveStock()        → transaksi ACID di inventory_schema (strong)
2. createOrder()         → transaksi ACID di ordering_schema (strong)
3. charge() ke gateway   → idempotency key, retry aman (strong hasil)
4. PaymentReceived       → outbox → kafka (eventual)
5. shipping menerima     → jadwalkan pengiriman (eventual)
6. analytics menerima    → pipeline laporan (eventual)

Perhatikan desainnya: strong consistency dibayar hanya di tiga langkah pertama yang benar-benar menuntutnya. Sisa aliran memakai eventual via event — inilah komposisi konsistensi yang bijak, bukan strong-everywhere yang lambat atau eventual-everywhere yang berbahaya.

#Kesalahan Umum

• ORM-driven modeling — skema lahir dari struktur class framework, bukan dari domain. Hasilnya tabel yang mustahil dilaporkan dan migrasi yang menyakitkan.
• Shared database diam-diam — modul lain membaca tabel milik tetangga "sementara". Pelanggaran boundary paling destruktif karena invisible di code review biasa.
• NoSQL untuk menghindari skema — skema tidak hilang; ia hanya pindah ke asumsi implisit di kode aplikasi yang lebih sulit diaudit.
• Denormalisasi tanpa strategi sync — salinan data basi selamanya karena tidak ada mekanisme pembaruannya.
• Eventual consistency di jalur uang — refund ganda atau saldo minus adalah harga klasik salah memilih titik di spektrum konsistensi.

#Penutup

Inti yang harus dibawa pulang:

• Pemodelan data tiga level: conceptual untuk bisnis, logical untuk arsitek, physical untuk implementasi — jangan melompat.
• Polyglot persistence pilih per pola akses; setiap datastore baru adalah biaya operasional permanen.
• Konsistensi adalah spektrum per aliran data: strong untuk stok & pembayaran, eventual untuk sisanya — dengan PACELC sebagai intuisi harian.
• Kepemilikan data mengikuti modul; duplikasi sadar + outbox pattern adalah cara integrasi yang aman.
• CQRS untuk rasio baca-tulis ekstrem, bukan untuk CRUD biasa.
• Studi kasus kini punya peta kepemilikan data dan flow konsistensi checkout yang eksplisit.

Di episode 9 selanjutnya kita bahas API design & contracts — merancang interface antar modul dan keluar sistem, versioning tanpa mematahkan konsumen, dan contract testing agar perubahan tidak lagi mengejutkan. Sampai jumpa!