Belajar Redis - Sejarah, Konsep & Mengapa Memilih Redis

#Pendahuluan

Episode 0 sudah memastikan environment kalian siap. Sekarang saatnya memahami mengapa Redis ada dan mengapa kalian harus mempelajarinya. Episode 1 ini menjawab tiga pertanyaan besar: dari mana Redis berasal, apa sebenarnya Redis itu, dan mengapa dia layak dipilih dibanding alternatif lain.

Banyak orang memakai Redis hanya karena tutorial, padahal memahami konteks sejarah dan konsepnya jauh lebih berharga. Dengan tahu masalah yang diselesaikan, kalian akan lebih mudah memutuskan kapan memakai Redis, kapan tidak, dan bagaimana memposisikannya dalam arsitektur aplikasi. Mari mulai dari awal cerita.

#Sejarah Redis

#Lahir dari Tangan antirez

Redis diciptakan oleh Salvatore Sanfilippo, yang dikenal komunitas sebagai antirez, pada tahun 2009 di Italia. Awalnya ini bukan proyek besar: antirez mengembangkan Redis untuk proyek analitik real-time yang sedang ia kerjakan, dan membutuhkan database yang jauh lebih cepat daripada solusi yang ada saat itu.

Kecepatan dan kesederhanaan desain Redis menarik perhatian komunitas open-source dengan sangat cepat. Pada tahun 2010, VMware mulai mensponsori pengembangan, lalu dilanjutkan oleh Pivotal pada 2013, dan akhirnya berdirilah perusahaan Redis Labs (kini Redis Ltd) pada 2015 sebagai rumah komersial proyek ini.

#Perubahan Lisensi dan Fork Valkey

Bulan Maret 2024 menjadi titik balik besar. Redis Ltd mengubah lisensi Redis menjadi SSPL dan RSALv2 — bukan lagi BSD yang permisif. Akibatnya, Linux Foundation meluncurkan fork bernama Valkey, yang merupakan kelanjutan langsung dari kode Redis terakhir berlisensi BSD.

redis-cli INFO server | grep redis_version

redis-cli INFO server | grep redis_version menampilkan versi Redis kalian. Jika kalian menjalankan Redis di Docker dengan image resmi, versinya adalah Redis 7.x. Perlu kalian tahu bahwa banyak cloud provider dan distro kini menawarkan Valkey sebagai pengganti drop-in — sebagian besar perintah yang akan kita pelajari di series ini identik di keduanya.

#Konsep Dasar Redis

#In-Memory Data Structure Store

Redis adalah in-memory data structure store: semua data disimpan di RAM, bukan di disk. Akses datanya berlatensi sub-milidetik (umumnya di bawah 1ms), jauh lebih cepat dibanding database disk-based yang harus membaca dari storage fisik.

L1/L2 cache (nanodetik)
  → Redis (RAM, sub-milidetik)
      → SQL/NoSQL disk-based (milidetik - puluhan milidetik)
          → Cold storage (detik)

Justru karena data di RAM itulah Redis sangat cepat — tapi itu juga mengapa memori terbatas dan mengapa persistence (episode 2) menjadi keputusan arsitektur yang penting.

#Lebih dari Sekadar Key-Value

Istilah "key-value store" sering menyesatkan. Redis bukan sekadar SET key value sederhana. Dia mendukung rich data structures:

• Strings untuk cache dan counter.
• Lists untuk queue dan timeline.
• Hashes untuk objek dan session.
• Sets dan Sorted Sets untuk tag, unik visitor, dan leaderboard.
• Streams untuk event streaming dan message broker.
• Bitmaps, geospatial, dan HyperLogLog untuk use case khusus.

Semua struktur ini beroperasi di server-side, yang berarti operasi seperti INCR atau SINTER berjalan atomik tanpa perlu membawa data ke aplikasi. Inilah yang membuat Redis dipakai di hampir semua aplikasi berskala besar.

#Mengapa Memilih Redis

#Performa Ekstrem

Redis sanggup menjalankan 100.000+ operasi per detik pada single instance, berkat desain single-threaded yang menghindari konflik locking. Angka ini membuat Redis menjadi pilihan utama untuk jalur paling kritis performa aplikasi.

#Versatilitas Use Case

Satu server Redis bisa melayani banyak peran sekaligus:

• Cache untuk akselerasi database dan API.
• Session store untuk login state di aplikasi web.
• Message broker untuk job queue dan pub/sub.
• Rate limiter untuk melindungi API dari abuse.
• Leaderboard dan real-time analytics.
• Distributed lock untuk koordinasi antar instance aplikasi.

Karena satu tool bisa mengerjakan semua ini, tim tidak perlu mengoperasikan lima infrastruktur terpisah. Ini alasan besar mengapa Redis mendominasi.

#Redis vs Alternatif Lain

#Tabel Perbandingan

Untuk memposisikan Redis dengan benar, bandingkan dengan para pesaingnya:

#Kapan Memakai Apa

Memcached hanya cocok untuk cache KV murni tanpa struktur data dan tanpa persistence. KeyDB dan DragonflyDB menarik jika kalian butuh throughput yang lebih besar dari satu core CPU karena desain multi-threaded-nya. Valkey adalah pilihan jika kalian menginginkan kepastian lisensi open-source dengan pengalaman Redis yang sama persis.

Untuk mayoritas kebutuhan — dukungan komunitas terbesar, dokumentasi paling lengkap, fitur terlengkap seperti Redis Modules dan Streams — Redis tetap pilihan paling aman, dengan Valkey sebagai alternatif drop-in yang patut dipantau.

#Penutup

Episode 1 memberi kalian konteks: Redis lahir tahun 2009 dari tangan Salvatore Sanfilippo, berubah lisensi pada 2024 sehingga memunculkan fork Valkey, dan kini menjadi in-memory data structure store paling populer dengan latensi sub-milidetik dan 100.000+ operasi per detik.

Inti yang harus dibawa pulang:

• Redis diciptakan antirez pada 2009 dan berkembang jadi proyek dengan sponsor komersial.
• Perubahan lisensi 2024 ke SSPL/RSALv2 memunculkan Valkey sebagai fork open-source.
• Redis menyimpan data di RAM, menghasilkan latensi di bawah 1 milidetik.
• Redis bukan sekadar key-value: ada strings, lists, hashes, sets, sorted sets, dan streams.
• Performa single-threaded bisa mencapai 100.000+ operasi per detik.
• Redis vs Memcached/KeyDB/DragonflyDB: pilih berdasarkan fitur, lisensi, dan throughput.

Di episode 2 selanjutnya kita akan membahas arsitektur internal dan persistence model — cara kerja single-threaded event loop dengan I/O multiplexing, kenapa Redis tetap cepat meski single-threaded, serta perbedaan RDB, AOF, dan kombinasi keduanya dalam menyimpan data dari RAM ke disk. Ini fondasi arsitektural yang akan menemani seluruh series.