Arsitektur Reporting ERP: Read Model Penyelamat Database OLTP

Tiket support yang mengajari saya pelajaran ini berbunyi: simpan invoice butuh 30 detik setiap pagi sekitar jam 8. Penyebabnya sama sekali bukan di kode invoice. Penyebabnya dashboard eksekutif — enam widget, masing-masing menjalankan agregasi lima tabel atas setahun transaksi, di-refresh setiap kali manajer membuka halaman sambil ngopi pagi. Instance PostgreSQL yang sama yang memproses posting invoice digilas query GROUP BY.

Inilah masalah arsitektur paling mendasar di reporting ERP: kerja transaksional dan kerja analitis punya pola akses berlawanan, dan database yang di-tuning untuk satu pasti biasa-biasa saja di yang lain. Solusinya bukan server lebih besar. Solusinya read model — salinan data yang sudah dihitung dan dibentuk sesuai query, yang dipukul dashboard alih-alih tabel live. Berikut arsitektur yang saya pakai di NestJS dan PostgreSQL, dari materialized view pertama sampai tahu kapan Anda melampauinya.

Kenapa Reporting Membunuh Database OLTP Anda

Beban kerja OLTP — posting invoice, mengeluarkan stok, approve PO — menyentuh segelintir baris, menuntut latensi milidetik, dan berjalan ribuan kali sehari. Query analitis memindai jutaan baris, men-join separuh skema, dan mengagregasi berbulan-bulan data. Menjalankan keduanya di satu database menyakitkan dalam tiga cara spesifik:

• Penggusuran cache — satu full-table scan untuk grafik penjualan tahunan bisa membilas working set baris panas (invoice terbuka, item aktif) keluar dari shared buffers, sehingga setiap transaksi setelahnya membayar pajak baca disk.
• Kelaparan resource — agregasi dashboard yang menyandera CPU dan I/O selama delapan detik menunda flush WAL dan update index yang sedang ditunggu commit transaksional.
• Interaksi lock dan bloat — transaksi laporan yang berjalan lama menahan vacuum di tabel sibuk, dead tuple menumpuk, dan point query yang dulu cepat terdegradasi diam-diam minggu demi minggu.

Insting pertama adalah menambah index untuk laporan. Itu membuat pembacaan sedikit lebih cepat sambil membuat setiap penulisan transaksional lebih lambat — tiap index ekstra adalah biaya write amplification yang dibayar di setiap INSERT. Setelah beberapa ronde, Anda punya skema OLTP berkostum OLAP, buruk di kedua pekerjaan.

Tangga Read Model: Empat Tahap Pemisahan

Anda tidak butuh data warehouse di hari pertama. Ada tangga pemisahan, dan tiap anak tangga membeli ruang napas dengan biayanya sendiri. Naik hanya saat pengukuran bilang Anda butuh anak tangga berikutnya:

Tahap Satu yang Benar: Materialized View di PostgreSQL

Untuk mayoritas ERP custom yang melayani puluhan sampai ratusan user, tahap satu cukup untuk bertahun-tahun — kalau dibangun dengan sengaja. Materialized view di PostgreSQL menyimpan hasil query sebagai tabel fisik yang bisa di-index; dokumentasinya menunjukkan percepatan empat orde magnitudo saat materialized view ber-index menggantikan komputasi berulang. Ini bentuk nyatanya, widget AR aging:

-- Read model for the AR aging dashboard widget
CREATE MATERIALIZED VIEW mv_ar_aging AS
SELECT
  c.id            AS customer_id,
  c.name          AS customer_name,
  SUM(i.open_amount) FILTER (WHERE age_days(i) <= 30)
                  AS bucket_current,
  SUM(i.open_amount) FILTER (WHERE age_days(i) BETWEEN 31 AND 60)
                  AS bucket_31_60,
  SUM(i.open_amount) FILTER (WHERE age_days(i) BETWEEN 61 AND 90)
                  AS bucket_61_90,
  SUM(i.open_amount) FILTER (WHERE age_days(i) > 90)
                  AS bucket_over_90,
  now()           AS refreshed_at
FROM ar_invoice i
JOIN customer c ON c.id = i.customer_id
WHERE i.status = 'OPEN'
GROUP BY c.id, c.name;

-- Unique index makes CONCURRENTLY possible
CREATE UNIQUE INDEX ON mv_ar_aging (customer_id);

-- Refresh WITHOUT blocking dashboard readers
REFRESH MATERIALIZED VIEW CONCURRENTLY mv_ar_aging;

Dua detail di cuplikan itu yang mengangkat beban berat. Unique index-lah yang memungkinkan REFRESH MATERIALIZED VIEW CONCURRENTLY, yang membangun ulang view tanpa mengambil exclusive lock yang akan membekukan semua dashboard di tengah refresh. Dan kolom refreshed_at menampilkan kesegaran data ke UI — kenapa itu penting dibahas di bawah.

Mendesain Read Model-nya Sendiri

Kesalahan pertama saya: membuat satu view raksasa per halaman laporan. View seharusnya dibentuk seperti widget, bukan halaman — satu materialized view per pertanyaan, masing-masing kecil, bisa di-refresh independen, dan dimiliki konsumen bernama. Saat ringkasan penjualan rusak, Anda me-refresh atau membangun ulang satu view, bukan seluruh dunia.

Ini pemikiran CQRS yang diterapkan di level database, dan panduan arsitektur Microsoft mengatakannya gamblang: read model melayani query dan tidak membawa logika bisnis, sementara write model menjaga konsistensi. Empat aturan menjaga read model ERP tetap jujur:

Kesegaran Data Itu Keputusan Produk, Bukan Teknis

Setiap read model pada dasarnya basi — pertanyaannya cuma seberapa basi, dan apakah user tahu. Di ERP ini sensitif: supervisor gudang yang mengecek stok sebelum menjanjikan pengiriman butuh kebenaran live; direktur yang meninjau tren pendapatan bulanan tidak peduli sepuluh menit terakhir. Jadi anggaran kesegaran harus datang dari user, widget per widget, bukan dari default engineering.

Default saya, dikalibrasi bertahun-tahun oleh tim finance yang memberi tahu apa yang benar-benar mereka cek: widget operasional (approval terbuka, penerimaan hari ini, stok menipis) datang dari query live ke tabel OLTP ber-index, sengaja dibuat mungil. Widget taktis (aging, penjualan bulanan, serapan budget) refresh tiap 15 sampai 60 menit. Widget strategis (tren tahunan, analisis margin) refresh tiap malam. Belum pernah ada yang komplain grafik tren year-over-year berumur empat jam.

Rencana Retrofit: Dari Dashboard Lambat ke Read Model

Kalau dashboard ERP Anda sudah menyakiti production, ini urutan yang saya ikuti — sudah menyelamatkan lebih dari satu deployment tanpa rewrite:

1. Ukur dulu: aktifkan pg_stat_statements, urutkan query berdasarkan total waktu eksekusi, dan pastikan dashboard memang pelakunya. Kadang penjahatnya justru foreign key tanpa index.
2. Pindahkan tiga pelaku teratas ke materialized view dengan unique index; arahkan API ke sana dengan bentuk response yang sama supaya frontend tidak berubah.
3. Tambahkan job refresh dengan logging dan kolom kesegaran; tampilkan timestamp-nya di UI dalam rilis yang sama.
4. Set statement_timeout untuk role database reporting, supaya tidak ada query ad-hoc masa depan yang bisa menyandera OLTP bermenit-menit lagi.
5. Negosiasikan anggaran kesegaran per widget dengan user sebenarnya — tuliskan; sekarang itu requirement, bukan kebetulan.
6. Ukur ulang setelah dua minggu. Hanya kalau beban refresh-nya sendiri kini jadi masalah, Anda naik ke replica atau read store berbasis event.

Intinya

Beban reporting bukan masalah optimasi di dalam database OLTP Anda — ia beban kerja berbeda yang layak mendapat struktur datanya sendiri. Read model memberinya struktur itu dengan biaya yang Anda kendalikan: beberapa tabel ringkasan, jadwal refresh, dan timestamp yang terlihat. Setiap anak tangga setelahnya adalah respons terukur terhadap beban nyata, bukan arsitektur mengawang.

Dashboard dari tiket invoice-30-detik itu hari ini berjalan di atas sebelas materialized view, di-refresh tiap 30 menit, di instance database yang sama. Invoice tersimpan dalam 200 milidetik jam 8 pagi. Pemisahan, bukan hardware, jawabannya — dan biasanya memang begitu.