Kisah seorang developer tentang ekstremitas database telah memicu perdebatan sengit mengenai pendekatan yang tepat untuk penyimpanan data dan logika bisnis. Cerita ini mengisahkan perjalanan sebuah tim dari mimpi buruk stored procedure menuju solusi key-value store yang sama-sama bermasalah, menyoroti bagaimana keputusan arsitektural dapat berayun dari satu ekstrem ke ekstrem lainnya tanpa menemukan titik yang tepat.
Masalah Awal: Stored Procedure yang Tak Terkendali
Sistem lama mengalami kasus klasik overengineering database. Logika bisnis sepenuhnya berada dalam stored procedure yang menampilkan join kompleks yang mencakup beberapa database SQL Server. Procedure ini menjadi bottleneck performa, menghabiskan waktu CPU pada server database yang terbatas dan menciptakan masalah latensi yang tidak dapat diprediksi ketika query plan berubah secara tak terduga. Sistem juga sangat bergantung pada MSDTC ( Microsoft Distributed Transaction Coordinator ), yang sering menyebabkan deadlock dan gangguan sistem.
MSDTC: Layanan Microsoft yang mengoordinasikan transaksi di beberapa database atau sistem, tetapi terkenal karena menyebabkan deadlock dan masalah keandalan.
Masalah Sistem Asli:
- Logika bisnis tertanam dalam stored procedure yang kompleks
- Beberapa database SQL Server tersebar di server yang berbeda-beda
- Ketergantungan berat pada MSDTC yang menyebabkan deadlock
- Perubahan query plan yang tidak dapat diprediksi menyebabkan timeout
- Waktu build 15-30 menit memerlukan lingkungan pengembangan VM
Koreksi Berlebihan: Ekstremisme Key-Value Store
Sebagai respons terhadap masalah SQL mereka, tim arsitektur melakukan ayunan dramatis ke arah yang berlawanan. Mereka memutuskan untuk meninggalkan database relasional sepenuhnya, memilih key-value store primitif yang hanya menawarkan empat operasi dasar: baca, sisipkan, perbarui, dan hapus kunci tunggal. Tidak ada transaksi, tidak ada batching, tidak ada query kompleks yang diizinkan.
Pendekatan ini menciptakan masalah baru hampir seketika. Data bisnis yang sangat relasional harus diratakan menjadi dokumen JSON besar, terkadang mencapai ratusan kilobyte. Karena key-value store tidak memiliki fitur database dokumen, bahkan pembaruan kecil memerlukan pembacaan seluruh dokumen, membuat perubahan dalam kode aplikasi, kemudian menulis semuanya kembali. Tim akhirnya menambahkan kompresi untuk mengurangi overhead jaringan, tetapi ini membuat data tidak mungkin diperiksa dengan alat database standar.
Keterbatasan Key-Value Store:
- Hanya 4 operasi: Read, Insert, Update, Delete untuk kunci tunggal
- Tidak mendukung transaksi atau batching
- Dokumen JSON mencapai ratusan kilobyte
- Memerlukan pembacaan/penulisan dokumen lengkap untuk pembaruan parsial
- Diperlukan kompresi Gzip, yang merusak kompatibilitas dengan perangkat standar
Ledakan Kompleksitas: Sistem Checkpointing
Tanpa transaksi database, tim membangun sistem checkpointing yang rumit untuk menangani konsistensi data. Setiap operasi tulis memerlukan pembuatan UUID dan menyimpannya sebagai checkpoint, kemudian menanamkan UUID ini dalam dokumen target untuk mencegah operasi duplikat selama retry. Pendekatan ini hampir menggandakan jumlah perjalanan database dibandingkan dengan sistem asli, membuat masalah latensi menjadi lebih buruk daripada lebih baik.
Dalam praktiknya, penulisan ke database yang sama yang sebelumnya memerlukan 5-10 perjalanan, sekarang memerlukan hampir dua kali lipat jumlah perjalanan untuk operasi checkpointing tambahan.
Overhead Sistem Checkpointing:
- Pembuatan UUID untuk setiap operasi penulisan
- Penyimpanan checkpoint dalam sistem terpisah
- Penyisipan UUID ke dalam dokumen target
- Hampir menggandakan perjalanan database (5-10 menjadi ~20)
- Logika retry yang kompleks untuk idempotency
Perspektif Komunitas: Perdebatan Jalan Tengah
Komunitas developer tetap terpecah secara mendalam mengenai pilihan arsitektur database. Banyak developer berbagi cerita horor tentang stored procedure yang menjadi monster yang tidak dapat dipelihara, dengan logika bisnis tersebar di berbagai sistem dan bahasa database. Yang lain berpendapat bahwa stored procedure masih memiliki tempatnya, terutama untuk operasi data massal dan ketika beberapa aplikasi perlu mengakses database yang sama dengan aturan bisnis yang konsisten.
Perdebatan ORM versus raw SQL juga muncul kuat dalam diskusi. Beberapa developer melihat ORM sebagai peningkat produktivitas yang menghemat waktu meskipun ada biaya performa, sementara yang lain melihatnya sebagai abstraksi yang menyembunyikan peluang optimisasi database yang penting. Konsensusnya tampaknya adalah bahwa kepatuhan religius terhadap pendekatan tunggal apa pun sering mengarah pada masalah.
ORM: Alat Object-Relational Mapping yang menerjemahkan antara tabel database dan objek bahasa pemrograman, membuat operasi database lebih mudah tetapi terkadang kurang efisien.
Pelajaran dalam Keseimbangan Arsitektural
Cerita ini menggambarkan pola umum dalam pengembangan perangkat lunak: memecahkan satu masalah ekstrem dengan berayun ke ekstrem yang berlawanan. Pendekatan stored procedure asli memiliki masalah yang sah, tetapi solusi key-value membuang dekade optimisasi database bersama dengan masalahnya. Pendekatan yang lebih terukur mungkin melibatkan refactoring stored procedure, meningkatkan strategi indexing, atau mengadopsi ORM modern dengan pemantauan performa yang cermat.
Kisah ini berfungsi sebagai pengingat bahwa keputusan arsitektural harus didasarkan pada persyaratan teknis spesifik daripada reaksi terhadap titik-titik rasa sakit masa lalu. Terkadang solusi terbaik tidak terletak pada perubahan revolusioner, tetapi dalam perbaikan evolusioner pada sistem yang ada.
Referensi: Wrong ways to use the databases, when the pendulum swung too far