Strategi Advanced Caching dan Pub/Sub Messaging Menggunakan Redis

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap arsitektur web modern yang menuntut latensi sub-milidetik, ketergantungan penuh pada database relasional konvensional seperti MySQL atau MariaDB untuk setiap operasi baca (read) dan tulis (write) adalah resep bencana bagi skalabilitas. Ketika sebuah platform web mengalami lonjakan trafik, misalnya dari ribuan menjadi ratusan ribu requests per second (RPS), database relasional akan menghadapi titik jenuh. Bottleneck utama terletak pada keterbatasan I/O disk, kompleksitas eksekusi query (query parsing and execution plans), serta overhead penguncian tabel atau baris (table/row-level locking).

Sebelum penerapan strategi caching berbasis in-memory seperti Redis, sebuah sistem umumnya mengandalkan kueri langsung ke database untuk setiap permintaan halaman, pemanggilan API, maupun status sesi pengguna. Kondisi ini memicu lonjakan penggunaan CPU pada server database, peningkatan connection pool exhaustion, dan penundaan respons HTTP yang berujung pada buruknya pengalaman pengguna (user experience) serta potensi kegagalan sistem secara total (cascading failure).

Sesudah penerapan Redis sebagai lapisan distributed caching dan message broker (Pub/Sub), arsitektur web mengalami pergeseran paradigma. Data yang sering diakses (hot data) disimpan langsung di dalam RAM, memangkas latensi pembacaan dari kisaran puluhan milidetik (pada disk SSD/NVMe) menjadi sub-milidetik. Selain itu, fitur Pub/Sub memungkinkan komunikasi asinkron antar-layanan secara real-time tanpa membebani database utama, sementara mekanisme distributed locking memastikan konsistensi data pada operasi konkuren yang kritis.