AI agent bisa kelihatan pintar di demo, tapi tetap terasa bodoh kalau setiap ambil data user butuh beberapa detik.
Artikel ini membahas pelajaran dari Spotify Random Access Parquet (RAP): AI agent yang berguna bukan cuma butuh model besar dan prompt rapi, tapi juga jalur akses data yang cepat, murah, dan bisa dipercaya. Buat developer backend, poin utamanya sederhana: jangan semua problem retrieval langsung dipindahkan ke key-value store mahal. Kadang data lake tetap bisa dipakai buat query interaktif kalau format, index, dan pola aksesnya didesain dari awal.
Apa itu Spotify Random Access Parquet?
Spotify Random Access Parquet, atau RAP, adalah pendekatan Spotify untuk membuat data di data lake bisa diakses lewat point query secara lebih interaktif. Data lake biasanya enak buat batch processing, analytics, machine learning, dan query besar. Masalahnya, data lake sering kurang cocok ketika aplikasi online atau AI agent butuh jawaban cepat untuk satu user, satu key, atau satu potongan data kecil.
Di artikel engineering-nya, Spotify menjelaskan problem yang sangat realistis: data user dalam skala besar disimpan di data lake seperti GCS atau S3, sementara layanan online dan AI agent butuh lookup cepat. Contohnya, agent yang menjawab pertanyaan seperti “apa yang gua dengerin musim panas lalu?” harus mengambil data listening history dengan latency yang masuk akal sebelum bisa menyusun konteks buat LLM.
RAP mencoba mengambil jalan tengah. Data tetap tinggal di Parquet, format kolumnar yang sudah umum dipakai di ekosistem data. Lalu Spotify menambahkan external index yang memetakan key ke lokasi data di file, sehingga sistem bisa melakukan ranged read ke bagian file yang relevan, bukan membaca dataset besar dari awal.
Kenapa data lake sering lambat buat query kecil?
Data lake kuat saat lu memproses data besar. Kalau lu mau agregasi jutaan atau miliaran baris, engine seperti Trino, Spark, atau BigQuery punya tempatnya. Tapi kalau lu cuma butuh beberapa record untuk satu user, overhead query engine bisa terasa terlalu besar. Startup time, planning, metadata scan, network hop, dan file listing bisa bikin query kecil terasa lambat.
Analogi sederhananya: gudang besar bagus buat menyimpan banyak barang, tapi kurang enak kalau setiap kali ambil satu baut kecil lu harus menunggu forklift, supervisor, dan form pengambilan lengkap. Untuk produk interaktif, user tidak peduli gudang lu rapi. User cuma merasa fitur lu lemot.
Solusi paling umum adalah menggandakan data ke serving store seperti Bigtable, DynamoDB, Redis, atau database lain yang memang didesain buat lookup cepat. Ini valid. Tapi di skala besar, duplikasi data berarti biaya storage, pipeline sinkronisasi, consistency concern, dan operational burden tambahan. Spotify menyebut point query atas dataset besar terlalu mahal kalau semuanya harus resident di KV store.
Kenapa ini penting buat AI agent?
AI agent sering dibahas dari sisi model: lebih pintar, context window lebih panjang, tool use lebih banyak. Tapi agent yang benar-benar dipakai di produk butuh data yang benar, cepat, dan relevan. Kalau retrieval path lambat, LLM yang bagus tetap menunggu. Kalau retrieval path mahal, fitur yang viral di demo bisa jadi tidak ekonomis saat dipakai banyak user.
Di sinilah data layer jadi bagian dari kualitas AI product. Agent tidak cukup hanya bisa memanggil tool. Tool itu harus punya latency, cost, permission, dan observability yang jelas. Kalau agent harus menjawab pertanyaan personal, dia perlu mengambil data personal secara scoped: user mana, range waktu mana, field mana, dan batas aksesnya apa.
Menurut gua, ini pelajaran yang sering kelewat di obrolan AI. Banyak orang fokus ke prompt, padahal prompt cuma lapisan terakhir. Sebelum prompt, ada data contract, index, auth, cache, query planner, dan storage layout. Kalau lapisan bawah ini berantakan, output AI cuma terlihat meyakinkan tanpa benar-benar punya fondasi yang kuat.
Point query, index, dan ranged read: mental model praktisnya
Point query adalah query yang mengambil data berdasarkan key spesifik. Misalnya user ID, playlist ID, order ID, atau document ID. Berbeda dari query analytics yang membaca banyak row untuk membuat agregasi, point query biasanya kecil tapi harus cepat.
External index berperan seperti peta. Daripada sistem mencari data user dari banyak file Parquet, index memberi tahu kira-kira data itu ada di file mana dan offset mana. Setelah itu, sistem bisa meminta byte range tertentu dari object storage. API object storage seperti Amazon S3 mendukung pengambilan object, dan ranged request adalah pola umum untuk mengambil bagian tertentu dari file besar saat sistem tahu lokasi byte yang dibutuhkan.
Parquet sendiri cocok untuk data analytics karena struktur kolumnar, metadata, compression, dan ecosystem support yang luas. Tapi RAP menunjukkan bahwa dengan desain tambahan, format batch-friendly bisa diberi jalur akses yang lebih interaktif untuk pola query tertentu.
Jangan salah baca: ini bukan pengganti semua database
Bagian pentingnya: RAP bukan alasan buat semua tim membuang Postgres, Redis, atau database online lain. Kalau app lu masih kecil, data lu cukup muat di Postgres, dan query lu belum punya bottleneck nyata, solusi paling waras tetap yang simpel.
RAP menarik sebagai mental model, bukan resep universal. Dia cocok saat data lu sangat besar, sebagian besar sudah hidup di data lake, dan lu punya pola lookup tertentu yang cukup stabil. Kalau workload lu transactional, butuh write cepat, isolation, locking, atau constraint relational, data lake bukan tempat utama buat itu.
Kesalahan yang sering kejadian di engineering adalah lompat ke arsitektur keren sebelum problemnya jelas. Jangan bikin external index rumit cuma karena Spotify melakukannya. Ambil prinsipnya: pahami pola akses data, jangan cuma ikut bentuk teknologi.
Checklist sebelum lu bikin fitur AI berbasis data user
- Tulis query utama sebagai pertanyaan produk. Misalnya: “agent butuh 50 transaksi terakhir user dalam 300 ms,” bukan “pakai RAG.”
- Bedakan retrieval untuk demo dan production. Demo bisa lambat dan manual. Production butuh latency budget, retry, timeout, dan fallback.
- Hitung biaya per request. Jangan cuma hitung biaya LLM. Hitung storage read, query engine, cache, dan data transfer.
- Batasi scope data. Agent tidak perlu membaca semua data user kalau pertanyaannya cuma butuh range waktu tertentu.
- Pastikan permission ikut sampai data layer. Prompt bukan permission system. Query harus tetap dicek oleh auth dan policy.
- Log jalur retrieval. Saat jawaban AI salah, lu perlu tahu data apa yang diambil, bukan cuma chat history-nya.
Pelajaran buat developer kecil dan indie builder
Walaupun Spotify bermain di skala yang jauh lebih besar, pelajarannya tetap kepakai buat developer kecil. Banyak produk AI gagal bukan karena modelnya kurang pintar, tapi karena datanya tidak siap dipakai. Data tersebar di spreadsheet, database, file markdown, storage object, dan API internal tanpa kontrak yang jelas.
Kalau lu bikin produk kecil, versi sederhananya bisa begini: simpan data dengan struktur yang jelas, kasih ID yang konsisten, buat index yang masuk akal, dan jangan lupa path untuk export atau audit. Untuk banyak kasus, SQLite atau Postgres dengan index yang benar sudah cukup. Kalau data mulai pindah ke object storage, baru pikirkan apakah format file, partitioning, dan metadata lu mendukung retrieval yang dibutuhkan produk.
Gua suka angle Spotify RAP karena dia mengingatkan bahwa AI product bukan cuma “LLM + tool.” Produk AI yang terasa cepat dan berguna biasanya punya engineering boring di belakangnya: data layout, index, timeout, cache, dan permission.
Takeaway singkat
- AI agent yang berguna butuh data layer yang cepat, bukan cuma model yang pintar.
- Data lake bagus buat batch, tapi perlu desain tambahan kalau dipakai untuk query interaktif.
- External index dan ranged read bisa mengurangi kebutuhan menggandakan semua data ke serving store mahal.
- RAP bukan silver bullet. Cocok untuk pola point query tertentu, bukan transactional workload umum.
- Buat builder kecil, pelajarannya adalah desain data access pattern dulu sebelum menambah stack baru.
FAQ singkat
Apakah AI agent selalu butuh data lake?
Tidak. Banyak AI app cukup dengan Postgres, SQLite, vector database, atau API internal biasa. Data lake jadi relevan kalau data lu besar, historis, dan sudah dipakai banyak pipeline analytics atau machine learning.
Apakah Parquet cocok buat aplikasi online?
Secara default, Parquet lebih dikenal untuk analytics dan batch workload. Tapi dengan index, metadata, dan ranged read yang tepat, beberapa pola point query bisa dibuat lebih interaktif. Tetap lihat workload-nya dulu.
Kenapa tidak semua data langsung dimasukkan ke Redis atau DynamoDB?
Karena serving store cepat biasanya punya biaya dan operational tradeoff. Untuk data sangat besar, menggandakan semua data bisa mahal dan bikin pipeline makin kompleks.
Apa langkah paling praktis buat developer hari ini?
Ambil satu fitur AI yang sedang lu bikin, lalu tulis latency budget, data source, permission rule, dan biaya per request. Kalau empat hal itu belum jelas, masalahnya belum di prompt.
Penutup
AI agent yang bagus tidak dimulai dari prompt paling panjang. Dia dimulai dari pertanyaan yang jelas: data apa yang dibutuhkan, seberapa cepat harus diambil, siapa yang boleh mengakses, dan berapa biaya tiap request.
Spotify RAP menarik karena menunjukkan sisi AI yang lebih jarang dibahas: engineering data yang boring tapi menentukan pengalaman user. Buat rafli.dev, ini angle yang gua suka: AI itu berguna, tapi cuma kalau fondasi sistemnya ikut waras.
Kalau lu lagi bikin fitur AI, simpan takeaway ini: sebelum ganti model, cek dulu retrieval path lu. Bisa jadi bottleneck-nya bukan di LLM, tapi di cara app lu mengambil data.
