Pernah nggak kalian belanja di aplikasi e-commerce, klik tombol "Beli Sekarang", dan dalam hitungan kurang dari satu detik notifikasi "Pesanan Berhasil Dibuat!" langsung muncul?
Padahal di belakang layar, sistemnya harus ngejalanin segudang proses berat: validasi pembayaran, potong stok barang di gudang, bikin invoice PDF, kirim email konfirmasi, sampai kirim push notification ke HP kalian.
Kalau semua proses itu dikerjakan berurutan secara synchronous di satu request HTTP yang sama, pengguna mungkin harus nunggu 5 sampai 10 detik sambil menatap layar loading. Lebih parah lagi, kalau server pengirim email kebetulan lagi down, seluruh transaksi pembeliannya bisa ikut gagal. Masa gara-gara email, jualan ikut batal? 😅
Nah, rahasia di balik sistem yang tetap responsif dan tahan banting saat dihantam ribuan transaksi bersamaan adalah Event Queue, atau yang sering disebut juga Message Queue.
Poin Penting
- Event Queue itu komponen perantara yang nampung pesan sebelum diproses sistem lain, biar komunikasinya berubah dari saling menunggu jadi kirim-dan-lanjutkan.
- Aplikasi bisa balas sukses dalam milidetik, sementara pekerjaan beratnya dikerjakan worker di latar belakang.
- Producer dan consumer jadi nggak saling terikat, jadi salah satu layanan bisa di-restart tanpa bikin layanan lain ikut tumbang.
- Antrean juga berperan kayak spons penyerap lonjakan trafik, plus ada mekanisme retry dan Dead Letter Queue saat pemrosesan gagal.
- Pilihannya banyak: RabbitMQ buat routing yang fleksibel, Kafka buat streaming throughput besar, Redis Streams atau BullMQ buat setup ringan, dan Celery buat ekosistem Python.
Apa Sih Sebenarnya Event Queue Itu?
Secara sederhana, Event Queue itu komponen perantara atau buffer yang menampung pesan dan event sementara, sebelum diproses oleh sistem lain. Anggap aja kayak loket antrean di bank, tapi versinya buat pesan.
Pola ini jadi bagian inti dari Event-Driven Architecture, di mana komunikasi antar-komponen aplikasi berubah dari yang tadinya saling menunggu (blocking/synchronous) jadi sistem kirim-dan-lanjutkan (asynchronous).
Biar lebih gampang kebayang, bayangin aja dapur restoran cepat saji.
- Producer (kasir): nerima pesanan burger, nyatet tiketnya, lalu nempelin tiket itu ke papan antrean. Kasir langsung bisa melayani pelanggan berikutnya tanpa nunggu burgernya matang.
- Event Queue (papan antrean): tempat tiket-tiket pesanan berbaris rapi nunggu giliran.
- Consumer / worker (koki): ngambil tiket satu per satu dari papan antrean dan mulai memasak. Kalau pesanan lagi membeludak, restorannya tinggal nambah koki tanpa harus ngubah cara kerja kasir.
Dengan pembagian tugas kayak gini, pelanggan nggak perlu berdiri lama di depan kasir, dan dapurnya pun nggak kewalahan karena pesanan masuknya udah terstruktur.
Empat Alasan Kenapa Sistem Butuh Event Queue
1. Responsnya jadi super cepat
Aplikasi kalian bisa langsung balas sukses begitu event-nya berhasil masuk ke antrean. Pekerjaan berat yang makan waktu—render video, bikin laporan Excel, resize gambar—dikerjakan di latar belakang sebagai background job.
2. Producer dan consumer jadi nggak saling terikat
Pengirim pesan nggak perlu tahu siapa atau berapa banyak layanan yang bakal memprosesnya. Layanan notifikasi kalian bisa di-restart atau di-update tanpa ngeganggu layanan pemesanan barang.
3. Jadi spons penyerap lonjakan trafik
Pas flash sale atau hari gajian, trafik bisa melonjak 10 kali lipat dalam sekejap. Tanpa antrean, database dan server kalian bisa langsung crash karena kehabisan koneksi. Event queue nampung lonjakannya dengan aman, lalu worker memprosesnya sesuai kapasitas yang stabil.
4. Nggak gampang kehilangan pesan
Kalau satu worker kena kendala jaringan saat memproses, pesannya nggak hilang begitu aja. Message broker modern menyediakan mekanisme acknowledgment (ACK) dan Dead Letter Queue (DLQ) buat nyoba ulang pesan yang gagal secara otomatis.
Pilihan Message Broker yang Populer
Tergantung skala dan kebutuhan aplikasi kalian, ada beberapa teknologi yang lazim dipakai di industri nih:
- RabbitMQ: salah satu yang paling populer, mendukung protokol AMQP. Fleksibel buat routing pesan yang kompleks dan andal buat task queue.
- Apache Kafka: platform distributed event streaming dengan throughput raksasa. Cocok buat analitik real-time, log aggregation, dan event sourcing skala besar.
- Redis Streams & BullMQ: kalau kalian udah pakai Redis, Redis Streams atau library antrean kayak BullMQ (Node.js) ngasih solusi yang cepat, ringan, dan gampang di-setup.
- Celery: standar de facto buat task queue asinkron di ekosistem Python, terintegrasi mulus dengan Django maupun FastAPI.
Contoh Pola Sederhana di Backend Python
Berikut gambaran memisahkan tugas berat menggunakan BackgroundTasks di FastAPI:
from fastapi import FastAPI, BackgroundTasks
import time
app = FastAPI()
def process_heavy_task(email: str, order_id: str):
# Simulasi proses berat: generate invoice PDF & kirim email
time.sleep(3)
print(f"[Worker] Selesai memproses invoice #{order_id} untuk {email}")
@app.post("/api/checkout")
async def checkout(order_id: str, email: str, background_tasks: BackgroundTasks):
# 1. Simpan order ke database utama dengan cepat
# 2. Lempar pekerjaan beratnya ke antrean background
background_tasks.add_task(process_heavy_task, email, order_id)
# 3. Langsung balas ke user dalam beberapa milidetik
return {
"status": "success",
"message": f"Pesanan {order_id} diterima dan sedang diproses!",
}
Catatan penting nih: BackgroundTasks di FastAPI jalan di dalam proses aplikasi yang sama, jadi cocok buat prototipe dan tugas ringan. Kalau server-nya mati, tugas yang sedang jalan ikut hilang. Pada skala produksi, fungsi process_heavy_task biasanya dipisah ke service worker tersendiri yang mendengarkan event dari broker kayak RabbitMQ atau Redis.
Kapan Harus Pakai, Kapan Sebaiknya Tunda Dulu?
Menambah Event Queue itu juga nambah kompleksitas infrastruktur, karena ada komponen baru yang harus dimaintain dan dimonitor. Jadi jangan asal ikut-ikutan, ya.
Pakai kalau:
- Ada proses yang makan waktu lebih dari 500 milidetik (kirim email, olah media, ekspor file).
- Ada integrasi dengan API pihak ketiga yang rawan rate limit atau sering lambat merespons.
- Ada beberapa microservice yang perlu ngobrol secara asinkron.
Tunda dulu kalau:
- Aplikasi kalian masih CRUD internal sederhana dengan trafik rendah. Nambah RabbitMQ di sini malah bikin repot tanpa manfaat yang sepadan, tuh.
- Alur bisnisnya beneran butuh hasil instan di response HTTP yang sama, misal validasi password saat login.
Event Queue itu salah satu fondasi terpenting di system design modern. Dengan memisahkan penerimaan request dari pemrosesan tugas beratnya, backend kalian nggak cuma jadi jauh lebih gesit, tapi juga punya daya tahan tinggi saat dihantam badai trafik yang nggak terduga.
Selamat ber-event queue ria, dan semoga antrean kalian selalu rapi! 👋