SNS vs SQS vs Kinesis: Berhenti Menebak, Mulai Memilih

SNS vs SQS vs Kinesis: Berhenti Menebak, Mulai Memilih

Aku akan jujur. Pertama kali aku harus milih antara SNS dan SQS, aku menatap console AWS selama 40 menit, buka tujuh tab, dan tetap aja ragu sama keputusanku sendiri. Itu dulu, bertahun-tahun lalu. Sekarang AWS punya enam—ya, enam—layanan pengiriman event yang berbeda. Bahkan arsitek senior pun bisa kewalahan.

Padahal sebenarnya ini bukan masalah yang susah, asal kamu berhenti memikirkan layanannya dan mulai memikirkan *bentuk* datanya. Kamu butuh push atau pull? Replay? Fan-out? Routing berdasarkan konten? Nah, itu keputusan yang sebenarnya.

Aku akan jabarkan pakai framework yang dulu banget aku harap ada.

Para Kontestan (Primer Singkat, Agak Miring)

SNS — Si Pengeras Suara

SNS (Simple Notification Service, https://aws.amazon.com/sns/) itu layanan pub/sub dengan model push. Kamu publish satu pesan, SNS langsung dorong ke semua subscriber—fungsi Lambda, queue SQS, endpoint HTTP, email, bahkan notifikasi mobile. Prinsipnya fire-and-forget: SNS nggak nyimpen pesan dan jarang banget retry. Kalau nggak ada yang denger, pesannya hilang.

**Pakai kalau:** satu event harus memicu banyak aksi sekaligus.

SQS — Si Antrean Andal

SQS (https://aws.amazon.com/sqs/) adalah queue berbasis pull. Producer masukin pesan, consumer polling dan proses sesuai kecepatan mereka sendiri. Ini bukan pub/sub—ini point-to-point. Pesan bisa bertahan sampai 14 hari, dan queue FIFO kasih urutan ketat plus pemrosesan exactly-once.

**Pakai kalau:** kamu mau memisahkan producer dari consumer dan butuh keandalan tanpa routing yang ribet.

Kinesis — Si Pita Mesin Waktu

Kinesis (https://aws.amazon.com/kinesis/) adalah platform streaming data. Bedanya sama SQS, pesan di SQS itu habis sekali dibaca lalu dihapus. Kinesis memungkinkan banyak consumer membaca stream yang sama secara independen dan bisa replay data sampai 365 hari. Kamu dapat urutan per shard yang solid dan throughput yang besar.

**Pakai kalau:** kamu punya data streaming volume tinggi dan butuh kemampuan replay.

MSK — Kafka Tanpa Pusing (Ya, Sedikit)

MSK (Managed Streaming for Apache Kafka, https://aws.amazon.com/msk/) adalah Kafka yang dikelola AWS. Kamu tetap dapat ekosistem Kafka lengkap—topics, partitions, consumer groups, Kafka Connect, ksqlDB—tanpa harus bangun cluster sendiri. Tapi kamu tetap bertanggung jawab untuk sizing broker, tuning, dan patch sistem operasi.

**Pakai kalau:** kamu sudah punya skill Kafka, butuh Kafka Connect, atau mau migrasi dari deployment Kafka yang sudah ada.

EventBridge — Si Router Cerdas

EventBridge (https://aws.amazon.com/eventbridge/) itu pendatang baru yang cepet banget dewasanya. Ini event bus dengan filtering dan routing berbasis konten yang kuat. Kamu nggak cuma publish dan berdoa—kamu bisa filter, transform, dan arahkan event ke target yang beda-beda tergantung isinya. EventBridge juga bisa menangani event terjadwal (cron bawaan) dan integrasi native dengan 140+ layanan AWS.

**Pakai kalau:** logika routing bergantung pada isi event, atau kamu lagi bangun arsitektur event-driven yang serius.

RabbitMQ — Si Veteran Teruji

RabbitMQ (https://www.rabbitmq.com/) adalah broker open-source yang sudah berumur lebih dari satu dekade. Dia mendukung banyak protokol (AMQP, MQTT, STOMP), kasih routing fleksibel dengan exchanges dan bindings, dan bisa jalan di mana aja. Di AWS, biasanya dijalankan di EC2 (https://aws.amazon.com/ec2/) atau pakai layanan kelolaan pihak ketiga.

**Pakai kalau:** kamu butuh pola routing kompleks kayak topic exchanges dengan wildcard, atau dukungan banyak protokol.

Matriks Keputusan (Contekan Kamu)

Berhenti bandingin tabel fitur. Jawab enam pertanyaan ini aja:

| Pertanyaan | Pilihan Terbaik |
|---|---|
| Butuh decoupling satu-ke-satu? | SQS |
| Butuh fan-out satu-ke-banyak? | SNS atau EventBridge |
| Banyak consumer independen? | Kinesis |
| Sudah paham Kafka atau butuh ekosistemnya? | MSK |
| Routing berdasarkan isi pesan? | EventBridge |
| Routing rumit/existing + banyak protokol? | RabbitMQ |

Filosofiku: **default ke layanan native AWS selama nggak ada alasan buat nggak.** Nyewa broker sendiri itu beban operasional yang nggak kamu perlukan di 2026.

Skenario Dunia Nyata

Skenario 1: Pipeline Pesanan E-Commerce

Kamu punya toko online. Saat pesanan masuk, kamu harus kirim email konfirmasi, update stok, picu pengiriman, dan kasih tahu tim deteksi fraud.

Ini fan-out klasik. Pilihanku: **SNS atau EventBridge**. Publish satu event "order.placed", SNS langsung dorong ke Lambda email, queue SQS inventory, dan layanan shipping secara bersamaan. Tapi kalau kamu butuh filtering (misalnya *hanya* kasih tahu fraud untuk pesanan di atas $100), aturan berbasis konten di EventBridge yang menang. Consumer jadi lebih simpel—mereka cuma nerima yang memang harus mereka terima.

Skenario 2: Analytics Clickstream

Platform kamu dapat jutaan klik per jam, dan tiga tim—analytics, ML, dan security—butuh konsumsi data yang sama secara independen. Semua tim mau replay minimal seminggu.

Ini wilayahnya **Kinesis**. Di SQS, kalau satu consumer baca pesan, pesan itu hilang buat yang lain. Kinesis Data Streams memungkinkan tiga consumer independen baca stream data yang sama secara bersamaan, masing-masing dengan kecepatannya sendiri. Kalau tim analytics kamu sudah lancar Kafka, MSK bisa jadi alternatif yang adil—tapi Kinesis lebih ringan perawatannya.

Skenario 3: Sistem Legacy dengan Routing Rumit

Kamu lagi modernisasi sistem point-of-sale lama yang pakai RabbitMQ dengan topic exchanges kayak `order.created.retail` dan `warehouse.stock.low`. Ada ratusan routing key yang terhubung ke service backend.

Pindahin logika itu ke SNS itu bakal brutal—SNS cuma dukung filtering subscriber yang dasar, bukan pola rumit. **RabbitMQ** atau **EventBridge** sama-sama bisa. EventBridge kasih integrasi AWS native dan schema registry, tapi rewiring ratusan aturan routing itu makan waktu. Tetap pakai RabbitMQ artinya usaha migrasi lebih kecil, tapi kamu bakal urus instance EC2 dalam waktu yang lama. Aku bakal pilih EventBridge cuma kalau timnya punya kapasitas; kalau nggak, jalanin RabbitMQ dulu dan fokus ke masalah yang lebih gede.

Tips Praktis dari Lapangan

1. **Mulai dengan SQS + Lambda.** Ini pola asinkron paling simpel di AWS. Nanganin 90% kebutuhan decoupling backend. Tambah SNS kalau butuh fan-out, EventBridge kalau butuh routing yang cerdas.

2. **Pikirin replay dari hari pertama.** Pertanyaan susahnya bukan "bisakah service aku menangani pesan yang gagal?" Tapi "bisakah service aku menangani *baca ulang pesan yang sama dua kali*?" Kinesis dan MSK bikin replay terasa alami. SQS FIFO kasih semantik exactly-once tapi batasi throughput.

3. **Hormati batas retensi.** SNS nggak nyimpen apa-apa. SQS mentok di 14 hari. Kinesis bisa sampai 365 hari dengan extended retention. MSK defaultnya 7 hari (bisa diatur lebih tinggi). Kalau kamu butuh jejak audit atau reprocessing, pilih yang sesuai.

4. **Pakai long polling di SQS.** Ini ngumpulin pesan sampai 20 detik daripada polling ke queue kosong terus-menerus. Satu perubahan ini doang bisa potong tagihan SQS kamu sampai 90%.

5. **Jangan bikin dapur penuh sesak.** Aku pernah lihat Lambda memicu topik SNS, yang publish ke queue SQS, yang dorong ke Lambda lain, yang buang ke Kinesis—padahal cuma buat upload file. Setiap hop nambah latensi dan mode kegagalan baru. Cuma karena kamu bisa merantai semuanya, bukan berarti kamu harus.

FAQ

Apakah SNS dan SQS bisa dipakai bersamaan?

Bisa banget—dan ini salah satu pola terkuat di AWS. SNS fan-out ke beberapa queue SQS, dan tiap queue diproses independen oleh service yang berbeda. Ini menggabungkan kekuatan fan-out dari SNS dengan keandalan, retensi, dan retry dari SQS. Ini pola di balik kebanyakan arsitektur event-driven AWS yang serius.

Apakah EventBridge menggantikan SNS?

Belum sepenuhnya, tapi udah deket. EventBridge bisa semua yang SNS bisa—pub/sub, fan-out—plus filtering berbasis konten, schema discovery, dan integrasi AWS yang dalam. Untuk proyek baru, aku default ke EventBridge. Tapi kalau kamu cuma butuh push simpel ke Lambda, SNS masih lebih gampang dipahami dan dioperasikan.

Kapan harus pilih MSK daripada Kinesis?

Pilih MSK kalau tim kamu udah kenal Kafka, butuh Kafka Connect atau ksqlDB, atau lagi migrasi infrastruktur Kafka yang ada. Kinesis menang kalau kamu mulai dari nol, mau overhead operasional yang lebih kecil, dan nggak butuh ekosistem Kafka.

Apakah RabbitMQ mati di dunia AWS?

Nggak, tapi posisinya jadi niche. Dia unggul di logika routing yang rumit dan dukungan multi-protokol. Banyak enterprise masih menjalankan RabbitMQ di produksi. Tapi kalau kamu bangun greenfield di AWS, aku sangat prefer EventBridge atau Kinesis. Urus migrasinya sekali, dan berterima kasihlah pada dirimu sendiri nanti.

Penutup

Layanan messaging "terbaik" bukan yang punya fitur paling banyak. Yang terbaik adalah yang cocok dengan bentuk masalahmu: SQS untuk decoupling simpel. SNS untuk fan-out. Kinesis untuk streaming dengan replay. MSK untuk Kafka di skala besar. EventBridge untuk routing cerdas. RabbitMQ untuk kompleksitas gaya lama.

Sekarang kamu punya matriks keputusan mental yang dulu bisa nyelametin aku dari 40 menit dan tujuh tab di hari pertamaku. Ayo bikin sesuatu.