LMS-SPADA INDONESIA
1. Latar Belakang Perusahaan
Nusantara-Commerce adalah sebuah platform e-commerce yang berbasis di Surabaya, Indonesia. Didirikan pada tahun 2020, perusahaan ini awalnya fokus menjual produk-produk UMKM dari Jawa Timur. Dalam lima tahun, Nusantara-Commerce berkembang pesat dan kini menjadi salah satu pemain utama di tingkat nasional, dengan jutaan pengguna aktif setiap hari.
Arsitektur awal mereka dibangun menggunakan tumpukan teknologi yang umum pada saat itu: sebuah aplikasi monolitik yang terhubung ke basis data relasional (SQL) tunggal, seperti MySQL. Basis data ini menyimpan semua informasi krusial: data pengguna, katalog produk, data transaksi, inventaris, dan ulasan produk.
2. Masalah yang Timbul (Tantangan Skalabilitas)
Pada kuartal ketiga tahun 2025, menjelang festival belanja akhir tahun "Pesta Belanja 11.11", tim teknis Nusantara-Commerce mulai mengidentifikasi masalah-masalah kritis yang berulang:
Kinerja Lambat saat Peak Traffic: Setiap kali ada flash sale atau promosi besar, response time situs web dan aplikasi melambat drastis. Pengguna mengeluh tentang lamanya waktu loading halaman produk dan seringnya terjadi timeout saat proses checkout. Analisis menunjukkan bahwa basis data SQL menjadi bottleneck utama. Operasi JOIN yang kompleks untuk mengambil data produk (detail, stok, ulasan, nama penjual) sangat membebani server.
Kesulitan Menangani Data yang Beragam: Tim pemasaran ingin meluncurkan fitur baru: "Rekomendasi Produk Personalisasi" berdasarkan riwayat penjelajahan (browsing history), klik, dan item di keranjang belanja pengguna. Data ini bersifat tidak terstruktur dan semi-terstruktur (log klik, event stream), sangat berbeda dengan skema kaku pada tabel SQL. Memaksakan data ini ke dalam basis data relasional terasa rumit dan tidak efisien.
Skalabilitas Vertikal yang Mahal: Solusi sementara yang selama ini mereka lakukan adalah skalabilitas vertikal: meningkatkan spesifikasi server basis data (CPU, RAM, SSD). Namun, biaya untuk upgrade server high-end semakin mahal dan mereka mulai mencapai batas puncaknya. Skalabilitas horizontal (menambah lebih banyak server) sangat sulit diimplementasikan pada arsitektur basis data relasional monolitik mereka.
Struktur Katalog Produk yang Kaku: Setiap produk memiliki atribut yang berbeda-beda. Misalnya, sebuah smartphone memiliki atribut "RAM" dan "Ukuran Layar", sementara sepotong baju memiliki atribut "Ukuran" (S, M, L) dan "Bahan". Di basis data SQL, mereka terpaksa membuat banyak kolom yang seringkali kosong (NULL) di tabel produk, membuat skema menjadi tidak efisien dan sulit diubah jika ada kategori produk baru.
3. Pertanyaan untuk Diskusi dan Analisis
Anda adalah seorang arsitek data yang disewa oleh Nusantara-Commerce untuk mengatasi masalah ini. Jawablah pertanyaan-pertanyaan berikut:
Identifikasi Jenis Beban Kerja (Workload): Dari masalah yang dihadapi Nusantara-Commerce, identifikasi setidaknya tiga jenis data atau beban kerja yang berbeda (contoh: data transaksi, katalog produk, data sesi pengguna). Jelaskan mengapa basis data relasional kurang cocok untuk masing-masing beban kerja tersebut.
Pemilihan Model Basis Data NoSQL: Basis data NoSQL memiliki beberapa model utama (Key-Value, Document, Column-Family, Graph).
Untuk katalog produk dengan atribut yang dinamis, model NoSQL mana yang paling sesuai? Berikan alasan dan contoh struktur datanya (misalnya dalam format JSON).
Untuk menyimpan data sesi pengguna (riwayat klik, item di keranjang belanja), model NoSQL mana yang paling cocok? Jelaskan mengapa.
Apakah ada data yang sebaiknya tetap disimpan di basis data relasional? Jika ya, data apa dan mengapa?
Rancangan Arsitektur Baru (Hybrid): Usulkan sebuah rancangan arsitektur basis data baru yang bersifat hybrid (menggabungkan SQL dan NoSQL).
Gambarkan diagram sederhana yang menunjukkan bagaimana berbagai jenis data akan disimpan di basis data yang berbeda.
Jelaskan bagaimana aplikasi akan berinteraksi dengan kedua jenis basis data tersebut.
Keuntungan dan Tantangan Implementasi:
Apa saja keuntungan utama yang akan diperoleh Nusantara-Commerce setelah mengadopsi arsitektur baru ini, terutama dalam hal kinerja, skalabilitas, dan fleksibilitas?
Apa saja tantangan atau risiko yang mungkin mereka hadapi selama proses migrasi dari SQL ke NoSQL? (Contoh: konsistensi data, kebutuhan skill baru, dll).
Tujuan Studi Kasus:
Mendorong mahasiswa untuk memahami bahwa tidak ada satu solusi basis data yang cocok untuk semua masalah (one-size-fits-all).
Melatih kemampuan analisis untuk memetakan masalah bisnis ke solusi teknis (pemilihan model basis data).
Memperkenalkan konsep arsitektur polyglot persistence (penggunaan beberapa model basis data dalam satu aplikasi).
Mendorong diskusi tentang trade-off antara berbagai model basis data (misalnya, konsistensi vs. ketersediaan).