SNS vs SQS vs Kinesis: Tahmin Etme, Doğru Seç

SNS vs SQS vs Kinesis: Tahmin Etme, Doğru Seç

Dürüst olayım: SNS ile SQS arasında seçim yapmam gereken ilk seferde AWS konsoluna 40 dakika baktım, yedi sekme açtım ve yine de kendimi sorguladım. Yıllar önceydi o, ama bugün AWS'in — evet, altı — farklı olay teslim servisi var. Senior mimarlar için bile ezici bir durum.

Aslında bu, servisler yerine verinin *şekli* hakkında düşünmeye başladığınızda zor bir problem değil. Push mu pull mu lazım? Replay? Fan-out? İçerik tabanlı yönlendirme? Asıl karar bu.

Eskiden keşke elimde olsaydı diye düşündüğüm çerçeveyle kısaca anlatayım.

Adaylar (Hızlı, Kişisel Bir Özet)

SNS — Hoparlör
SNS (Simple Notification Service, https://aws.amazon.com/sns/) bir pub/sub push servisi. Mesaj yayınlarsınız, SNS derhal her aboneye iter — Lambda fonksiyonları, SQS kuyrukları, HTTP endpoint'leri, e-posta, hatta mobil push. Tasarım gereği fire-and-forget: SNS mesajları saklamaz, neredeyse tekrar denemez. Kimse dinlemiyorsa mesaj gider.

**Ne zaman:** tek bir olay aynı anda çoklu aksiyon tetiklemeli.

SQS — Güvenilir Kuyruk
SQS (https://aws.amazon.com/sqs/) pull-tabanlı bir kuyruk. Üreticiler mesajı bırakır, tüketiciler kendi tempolarında çekip işler. Bu pub/sub değil — point-to-point. Mesajlar 14 güne kadar yaşar, FIFO kuyruklarla sıralama ve exactly-once işleme garanti altına alınır.

**Ne zaman:** üreticiyi tüketiciye bağlamadan ayırmak, karmaşık yönlendirme olmadan güvenilirlik istiyorsanız.

Kinesis — Zaman Makinesi Teypi
Kinesis (https://aws.amazon.com/kinesis/) bir streaming veri platformu. SQS'te mesaj tüketilip silinirken, Kinesis birden fazla tüketicinin aynı stream'i bağımsız okuyup, veriyi 365 güne kadar tekrar oynamasını sağlar. Shard başına sağlam sıralama ve devasa throughput alırsınız.

**Ne zaman:** yüksek hacimli streaming veri var ve replay lazım.

MSK — Kafka Baş ağrısı Olmadan (Tamam, Azı)
MSK (Managed Streaming for Apache Kafka, https://aws.amazon.com/msk/) yönetilen Kafka. Topics, partitions, consumer groups, Kafka Connect, ksqlDB — tam Kafka ekosistemi, ama kümeyi siz kurmuyorsunuz. Yine de broker boyutlandırma, tuning, OS yamalama sizin sorumluluğunuz.

**Ne zaman:** zaten Kafka becerisi var, Kafka Connect lazım, veya mevcut Kafka deployment'u migrate ediliyor.

EventBridge — Akıllı Yönlendirici
EventBridge (https://aws.amazon.com/eventbridge/) hızlı büyüyen yeni oyuncu. Güçlü içerik tabanlı filtreleme ve yönlendirme ile bir event bus. Sadece yayınlayıp dua etmiyorsunuz — event'in içeriğine göre filtreleyip, transform edip, farklı hedeflere yönlendirebiliyorsunuz. Scheduled event'leri de hallediyor (içinde cron var) ve 140+ AWS servisiyle native entegre.

**Ne zaman:** yönlendirme mantığı event'in içeriğine bağlı, veya ciddi event-driven mimari kuruluyor.

RabbitMQ — Deneyimli Veteran
RabbitMQ (https://www.rabbitmq.com/) on yılı aşkın süredir açık kaynak broker. Çoklu protokol (AMQP, MQTT, STOMP), exchange ve binding'lerle esnek yönlendirme, her yerde çalışır. AWS'de genelde EC2 (https://aws.amazon.com/ec2/) üzerinde çalıştırılır veya managed üçüncü parti servis kullanılır.

**Ne zaman:** wildcard'lı topic exchange gibi karmaşık yönlendirme pattern'ları, veya multi-protocol destek lazım.

Karar Matrisi (Hile Kağıdınız)

Özellik tablolarını karşılaştırmayı bırakın. Bu altı soruyu sorun:

| Soru | En İyi Seçim |
|---|---|
| Bire-bir decoupling? | SQS |
| Birden çoka fan-out? | SNS veya EventBridge |
| Bağımsız birden fazla tüketici? | Kinesis |
| Kafka bilen ekip veya Kafka ekosistemi? | MSK |
| Mesaj içeriğine göre yönlendirme? | EventBridge |
| Karmaşık/mevcut yönlendirme + çok protokol? | RabbitMQ |

Felsefem şu: **AWS-native servisleri varsayılan yapın, yapmamak için bir nedeniniz olmadıkça.** 2026'da yönetmeniz gerekmeyen broker işletmek operasyonel yükten başka bir şey değil.

Gerçek Hayat Senaryoları

Senaryo 1: E-Ticaret Sipariş Pipeline'ı

Online mağazanız var. Sipariş alındığında onay e-postası gitmeli, envanter güncellenmeli, kargo tetiklenmeli, fraud detection uyarılmalı.

Klasik fan-out. Benim seçim: **SNS veya EventBridge**. Tek "order.placed" event'i yayınlanır, SNS bunu e-posta Lambda'sına, envanter SQS kuyruğuna, kargo servisine aynı anda iter. Ama filtreleme isterseniz (örneğin *sadece* 100$ üzeri siparişlerde fraud bildirimi), EventBridge'in content-based rule'ları kazanıyor. Tüketiciler daha basit oluyor — sadece işlerine düşeni alırlar.

Senaryo 2: Clickstream Analitiği

Saatte milyonlarca tıklama alan platformunuz var. Üç ekip — analitik, ML, güvenlik — bu veriyi bağımsız tüketmek istiyor. Herkes en az bir hafta replay istiyor.

Bu **Kinesis** işi. SQS'te bir tüketici mesajı okuduğu anda başkaları için yok oluyor. Kinesis Data Streams ile üç bağımsız tüketici aynı veriyi aynı anda, kendi hızlarında okur. Ekibiniz zaten Kafka biliyorsa MSK de haklı bir alternatif — ama Kinesis daha az operasyonel bakım istiyor.

Senaryo 3: Karmaşık Yönlendirmeli Legacy Sistem

Eski bir POS sistemi modernize ediliyor. RabbitMQ kullanıyor, `order.created.retail` ve `warehouse.stock.low` gibi topic exchange'ler var. Yüzlerce routing key backend servislerine bağlanmış.

Bunu SNS'e taşımak kabus — SNS sadece basit subscription filtering destekliyor, karmaşık pattern'lar yok. **RabbitMQ** veya **EventBridge** ikisi de çalışır. EventBridge native AWS entegrasyonu ve schema registry veriyor, ama o yüzlerce routing kuralını yeniden kablolamak zaman alıyor. RabbitMQ kalırsa migration eforu az, ama EC2 instance'ları yönetmek kalıyor gelecekte. Ekip bandwidth'i varsa EventBridge, yoksa RabbitMQ çalıştırıp daha önemli balıklarla uğraşırdım.

Önceki Deneyimlerden Pratik İpuçları

1. **SQS + Lambda ile başlayın.** AWS'deki en basit asenkron pattern. Backend decoupling ihtiyacının %90'ını halleder. Fan-out lazım olunca SNS, routing zekası lazım olunca EventBridge ekleyin.

2. **Gün birinden replay düşünün.** Zor soru "servisim başarısız mesajı handle edebilir mi?" değil. "Servisim *aynı mesajı iki kez okumayı* handle edebilir mi?" Kinesis ve MSK replay'i doğal hale getiriyor. SQS FIFO exactly-once veriyor ama throughput sınırlı.

3. **Saklama limitlerine saygı duyun.** SNS hiç saklamaz. SQS 14 gün üst limit. Kinesis extended retention ile 365 gün. MSK default 7 gün (artırılabilir). Audit trail veya reprocessing lazımsa buna göre seçin.

4. **SQS'de long polling kullanın.** 20 saniye mesaj biriktirip döner, sürekli boş kuyruk polling'i engeller. Bu tek değişiklik SQS faturanızı %90 düşürebilir.

5. **Mutfağın her şeyini koymayın.** Lambda → SNS → SQS → Lambda → Kinesis zinciri gördüm — basit bir dosya upload için. Her hop latency ve yeni bir failure mode ekliyor. *Yapabilirsiniz* demek *yapmalısınız* demek değil.

SSS

SNS ve SQS birlikte kullanılabilir mi?
Kesinlikle — ve AWS'deki en güçlü pattern'lerden biri. SNS birden fazla SQS kuyruğuna fan-out yapar, her kuyruk farklı servisler tarafından bağımsız işlenir. SNS'in fan-out gücü ile SQS'in güvenilirliği, saklaması ve retry'leri birleşir. Ciddi AWS event-driven mimarilerinin arkasında bu pattern yatar.

EventBridge SNS'i mi değiştiriyor?
Tam olarak değil, ama yaklaşıyor. EventBridge SNS'in yaptıklarını yapıyor — pub/sub, fan-out — üstüne content-based filtering, schema discovery, derin AWS entegrasyonu ekliyor. Yeni projelerde ben EventBridge'e default yapıyorum. Ama basit push-to-Lambda use case'iniz varsa SNS hâlâ daha basit anlaşıp işletilebiliyor.

MSK mi Kinesis mi seçmeliyim?
Ekibiniz zaten Kafka biliyorsa, Kafka Connect veya ksqlDB lazımsa, veya mevcut Kafka altyapısı migrate ediliyorsa MSK. Sıfırdan başlıyorsanız, operasyonel overhead az istiyorsanız ve Kafka ekosistemi lazım değilse Kinesis.

RabbitMQ AWS dünyasında öldü mü?
Hayır, ama niche. Karmaşık routing mantığı ve multi-protocol destekte parlıyor. Hâlâ çok enterprise production'da RabbitMQ var. Ama AWS'de greenfield yapıyorsanız EventBridge veya Kinesis'i güçlüce tercih ederim. Migration'ı bir kere yapıp sonra kendinize teşekkür edersiniz.

Son Sözler

"En iyi" mesaj servisi en çok özelliğe sahip olan değil. Sorununuzun şekline uyan o. SQS basit decoupling için. SNS fan-out için. Kinesis replay'li streaming için. MSK ölçekte Kafka için. EventBridge akıllı routing için. RabbitMQ eski okul karmaşıklığı için.

Artık elinizde, o ilk gün 40 dakikamı ve yedi segemi kurtaracak bir mental karar matrisi var. Gidin bir şeyler inşa edin.