Dalam perjalanan karier seorang Fullstack Developer, momen ketika aplikasi pertama kali diluncurkan ke tahap produksi (production) adalah momen yang paling memuaskan. Pada tahap awal, ketika data pengguna masih berjumlah ratusan atau ribuan, segala sesuatunya terasa berjalan mulus. Fitur pencarian cepat, daftar riwayat transaksi muncul seketika, dan navigasi halaman terasa responsif.
Namun, sering kali terdapat "bom waktu" arsitektural yang tertanam dalam kode yang kita tulis, yang baru akan meledak ketika aplikasi mencapai skala data jutaan baris (big data). Salah satu bom waktu yang paling umum, namun paling sering diabaikan, adalah mekanisme Pagination (pembagian halaman).
Hampir seluruh kerangka kerja web modern—mulai dari Laravel, Django, Ruby on Rails, hingga Spring Boot—menawarkan fitur pagination otomatis. Dengan satu baris kode seperti Model::paginate(10), pengembang sudah mendapatkan fitur navigasi halaman yang lengkap. Di balik layar, fitur ini menggunakan perintah SQL standar: LIMIT dan OFFSET.
Artikel ini tidak akan membahas cara membuat pagination. Artikel ini akan membongkar realita pahit bahwa metode yang diajarkan di hampir semua tutorial dasar tersebut adalah penyebab utama tingginya latensi server dan konsumsi CPU database yang berlebihan pada aplikasi berskala besar. Kita akan membedah secara teknis mengapa metode "Offset" gagal, dan bagaimana arsitektur "Cursor" (Keyset) menyelamatkan performa aplikasi kelas dunia.
Anatomi Masalah: Bagaimana Database Membaca Data
Untuk memahami mengapa aplikasi melambat pada "Halaman 10.000", kita harus berhenti memandang database sebagai kotak hitam ajaib dan mulai memahaminya sebagai mesin pemroses data yang logis.
Bayangkan Anda memiliki sebuah perpustakaan raksasa dengan satu juta buku yang berjajar di satu rak panjang.
Mekanisme Offset (Cara Lama)
Ketika Anda menjalankan perintah SQL: SELECT * FROM books LIMIT 10 OFFSET 500000;
Anda mungkin berasumsi bahwa database memiliki kemampuan teleportasi untuk langsung mendarat di buku urutan ke-500.001. Sayangnya, asumsi ini keliru. Database (khususnya relasional seperti MySQL atau PostgreSQL) bekerja secara sekuensial dalam konteks offset.
Yang sebenarnya terjadi adalah:
Database memulai dari indeks pertama.
Database "menghitung" dan membaca buku ke-1, ke-2, ke-3... terus menerus.
Database melakukan ini hingga mencapai buku ke-500.000.
Setelah lelah membaca 500.000 buku tersebut, database membuangnya (discard) karena Anda tidak memintanya.
Barulah database mengambil 10 buku selanjutnya untuk diberikan kepada Anda.
Dalam ilmu komputer, ini disebut kompleksitas O(N). Semakin besar angka halaman (N) yang diminta pengguna, semakin besar beban kerja database. Inilah sebabnya mengapa halaman 1 bisa dimuat dalam 10 milidetik, sementara halaman 50.000 bisa memakan waktu 5 detik atau bahkan menyebabkan time-out. Server Anda membakar siklus CPU hanya untuk membaca data yang akhirnya dibuang ke tempat sampah.
Masalah Kedua: "Data Drift" dan Inkonsistensi
Selain masalah performa, metode Offset memiliki cacat fatal dalam hal akurasi data pada sistem yang dinamis (Real-time).
Bayangkan skenario berikut pada sebuah toko online yang ramai:
Pengguna A sedang melihat Halaman 1 (Produk 1-10) yang diurutkan berdasarkan waktu terbaru.
Saat Pengguna A sedang membaca, admin toko menambahkan 5 produk baru.
Posisi produk di database bergeser. Produk yang tadinya ada di urutan ke-11 (awal Halaman 2), sekarang terdorong ke urutan ke-16.
Pengguna A menekan tombol "Next" ke Halaman 2.
Karena pergeseran data tersebut, Pengguna A akan melihat produk yang sama atau sebagian produk terlewati.
Fenomena ini disebut Skipped Item atau Duplicate Item issue. Dalam aplikasi keuangan atau audit log, masalah ini bukan sekadar gangguan visual, melainkan cacat integritas data yang serius. Metode Offset sangat rentan terhadap perubahan data yang terjadi saat pengguna sedang melakukan navigasi.
Solusi Arsitektural: Cursor Based Pagination
Jika metode Offset bekerja seperti orang yang menghitung manual dari awal, metode Cursor (Keyset Pagination) bekerja seperti penanda buku (bookmark).
Filosofinya sederhana: Jangan tanya halaman berapa, tapi tanyakan data apa yang terakhir dilihat.
Alih-alih menyuruh database untuk "melewati 500.000 baris", kita memberikan koordinat spesifik kepada database. Kita menggunakan kolom yang unik, berurutan, dan terindeks (seperti ID atau Timestamp) sebagai kursor.
Kueri SQL bertransformasi dari: OFFSET 500000 LIMIT 10
Menjadi: WHERE id < 500000 ORDER BY id DESC LIMIT 10
Mengapa Ini Jauh Lebih Cepat?
Di sinilah keajaiban struktur data B-Tree Index bekerja. Karena kolom id memiliki indeks:
Database tidak perlu memindai dari baris pertama.
Database melakukan "Index Seek" dan langsung melompat ke node di mana id = 500000 berada.
Database mengambil 10 baris setelahnya.
Proses ini memiliki kompleksitas O(1) atau konstan (logarithmic time jika memperhitungkan pencarian B-Tree). Artinya, beban server untuk memuat 10 transaksi pertama SAMA RINGANNYA dengan memuat 10 transaksi terakhir dari satu miliar data. Efisiensi yang ditawarkan bukan lagi peningkatan persen, melainkan peningkatan berkali-kali lipat (eksponensial).
Implementasi Teknis di Sisi Fullstack
Beralih ke Cursor Pagination menuntut perubahan pola pikir, baik di sisi Backend maupun Frontend. Anda tidak bisa lagi menggunakan logika page=1, page=2.
1. Perubahan API Backend Endpoint API Anda tidak lagi menerima parameter page. Gantinya, Anda menerima parameter cursor atau after.
Request: GET /api/products?limit=10Response:
JSON
{
"data": [...],
"meta": {
"has_next": true,
"next_cursor": "eyJpZCI6MTU0MzIsImNyZWF0Z..." // Token terenkripsi dari ID terakhir
}
}Token next_cursor biasanya adalah nilai ID dari item terakhir yang di-encode menggunakan Base64 agar terlihat rapi dan aman dari manipulasi URL sederhana.
2. Strategi Frontend Di sisi antarmuka pengguna (UI), metode Cursor sangat ideal untuk pola desain Infinite Scroll (seperti Instagram, Twitter, TikTok) atau tombol "Load More".
Namun, ada satu keterbatasan (trade-off) yang harus diterima: Hilangnya Navigasi Acak. Dengan Cursor Pagination, Anda tidak bisa membuat tombol navigasi halaman [1] [2] ... [Terakhir]. Anda tidak bisa melompat ke halaman acak. Pengguna harus menelusuri data secara linear. Inilah harga yang harus dibayar untuk performa dan stabilitas ekstrem.
Studi Kasus: Kapan Harus Migrasi?
Tidak semua tabel memerlukan Cursor Pagination. Sebagai insinyur perangkat lunak, keputusan harus didasarkan pada data dan kebutuhan, bukan sekadar tren.
Gunakan OFFSET (Bawaan Framework) Jika:
Data bersifat statis atau jarang berubah.
Jumlah data dipastikan kecil (kurang dari 10.000 baris).
Kebutuhan bisnis mewajibkan adanya navigasi halaman bernomor (seperti pada tabel Admin Panel internal).
Wajib Gunakan CURSOR Jika:
Tabel berpotensi tumbuh menjadi jutaan baris (Log aktivitas, Transaksi, Pesan chat).
Aplikasi menggunakan fitur Infinite Scroll di perangkat seluler.
Integritas urutan data sangat krusial (menghindari duplikasi saat navigasi).
Anda ingin menghindari lonjakan CPU database (CPU Spikes) yang tidak perlu.
Kesimpulan
Skalabilitas bukanlah fitur yang bisa ditambahkan belakangan; ia adalah pola pikir yang harus diterapkan sejak baris kode pertama. Memahami cara kerja database mengeksekusi kueri membedakan antara "Coder" (penulis kode) dan "Engineer" (perancang sistem).
Meskipun fitur pagination bawaan framework terasa menggoda karena kemudahannya, menyadari batasannya adalah langkah krusial. Transisi ke Cursor Based Pagination mungkin menambah kompleksitas kode di awal, namun ia memberikan jaminan bahwa aplikasi Anda tidak akan runtuh di bawah beban datanya sendiri di masa depan.
Dalam dunia Fullstack, performa adalah fitur. Dan cara terbaik mengoptimalkan performa adalah dengan berhenti menyuruh database melakukan pekerjaan sia-sia. Mulailah memeriksa kueri lambat (slow query log) Anda hari ini; mungkin "Offset" adalah pelakunya.
