M
MANTRA
Dashboard
Architecture Immutability ADR

Mengapa Keputusan Arsitektur Harus Immutable

ARSAKA Team ·

Masalah: Keputusan yang Menguap

Bayangkan skenario ini: tim Anda memutuskan menggunakan PostgreSQL RLS untuk multi-tenancy. Keputusan didiskusikan di meeting, disepakati semua orang, lalu… hilang. Tiga bulan kemudian, engineer baru bergabung dan bertanya, “Kenapa kita pakai RLS, bukan schema-per-tenant?”

Tidak ada yang ingat alasan lengkapnya.

Ini bukan masalah unik. Menurut survei ThoughtWorks Technology Radar, lebih dari 60% tim engineering tidak mendokumentasikan keputusan arsitektur secara konsisten. Yang lebih parah, keputusan yang sudah didokumentasikan sering di-edit atau dihapus tanpa jejak.

Architecture Decision Records (ADR)

ADR adalah langkah pertama yang tepat. Michael Nygard memperkenalkan konsep ini pada 2011: satu file per keputusan, format sederhana (Context, Decision, Status, Consequences).

Tapi ADR tradisional punya kelemahan:

  • Format tidak konsisten — setiap tim punya template sendiri
  • Tidak ada validasi — siapapun bisa menulis apapun
  • Tidak searchable oleh AI — plain text tanpa struktur
  • Bisa di-edit — keputusan bisa diubah tanpa jejak
  • Tidak ada enforcement — keputusan ada, tapi tidak dipaksa

Immutability: Pelajaran dari Blockchain & Git

Sistem yang serius tentang integritas data menggunakan immutability:

  • Git — setiap commit adalah snapshot immutable. Perubahan dibuat lewat commit baru, bukan edit commit lama.
  • Blockchain — setiap block immutable. State baru ditambahkan, bukan menimpa yang lama.
  • Event Sourcing — event tidak pernah dihapus atau diubah. State dihitung dari deretan event.

MANTRA mengambil prinsip yang sama untuk keputusan arsitektur.

Bagaimana MANTRA Menerapkan Immutability

1. Append-Only

Keputusan yang sudah disimpan tidak bisa di-UPDATE atau DELETE. Database trigger menolak semua operasi selain INSERT:

CREATE TRIGGER trigger_reject_all_updates
  BEFORE UPDATE OR DELETE ON decisions
  FOR EACH ROW
  EXECUTE FUNCTION reject_mutation();

2. Evolusi via Supersedes

Jika keputusan perlu di-update, buat versi baru yang supersedes versi lama:

  • ARCH-A06-001-v1.0.0 — “Gunakan PostgreSQL RLS” (original)
  • ARCH-A06-001-v2.0.0 — “Gunakan PostgreSQL RLS dengan shared schema” (supersedes v1)

Versi lama tetap ada. Audit trail lengkap.

3. Semantic Versioning

  • Major (v1 → v2): Perubahan breaking, pendekatan berbeda
  • Minor (v1.0 → v1.1): Penambahan detail, tidak breaking
  • Patch (v1.0.0 → v1.0.1): Klarifikasi, typo fix

Keuntungan Immutability

  1. Audit trail lengkap — tahu siapa membuat keputusan apa, kapan, dan mengapa
  2. Accountability — setiap keputusan punya created_by yang jelas
  3. Evolusi terlacak — bisa melihat bagaimana keputusan berkembang dari waktu ke waktu
  4. Tidak ada “siapa yang ubah ini?” — tidak ada yang bisa mengubah secara diam-diam
  5. AI-friendly — retrieval lebih akurat karena data konsisten

Kapan Immutability Tidak Cocok?

Immutability bukan untuk semua hal. Operational data (user profiles, settings, configurations) memang harus mutable. Tapi untuk keputusan arsitektur — yang mempengaruhi arah seluruh sistem — immutability adalah pilihan yang tepat.

Keputusan yang bisa diubah kapan saja bukan keputusan. Itu hanya opini sementara.

Mulai Sekarang

MANTRA membuat immutability mudah. Buat keputusan via dashboard atau MCP tool, validasi melalui 3-gate pipeline, dan simpan secara permanen. Jika perlu evolusi, supersedes. Jejak audit selalu lengkap.

Keputusan arsitektur terlalu penting untuk dibiarkan menguap.