Serverless Event-Driven Mimariler: SQS, SNS, EventBridge
Serverless mimarilerde bileşenler birbirini doğrudan çağırmak yerine olaylar (events) ve mesajlar üzerinden haberleşir. Bu gevşek bağlılık (loose coupling), sistemin ölçeklenebilirliğini ve dayanıklılığını artırır. AWS'de bu iletişimin üç temel yapı taşı vardır: SQS, SNS ve EventBridge. Her biri farklı bir iletişim modeli sunar ve doğru senaryoda kullanıldığında mimarinin bel kemiğini oluşturur.
1. Amazon SQS: Güvenilir Kuyruk (Pull-Based)
SQS, üretici ile tüketici arasında bir tampon (buffer) görevi görür. Üretici mesajı kuyruğa bırakır ve unutur; tüketici hazır olduğunda mesajı kendisi çeker (poll) .
Temel Özellikler:
-
Mesaj Kalıcılığı: Mesajlar tüketilene veya süresi dolana kadar (en fazla 14 gün) kuyrukta kalır .
-
Teslimat Garantisi: At-least-once (en az bir kez). Mesajlar birden fazla kez gelebilir; tüketici idempotent olmalıdır.
-
Sıralama: Standart kuyruklar sıralama garanti etmez; FIFO kuyrukları kesin sıralama sunar .
-
Hata Yönetimi: Dead-Letter Queue (DLQ) ile başarısız mesajlar izole edilir.
Ne Zaman Kullanılır?
-
Arka plan işleri (e-posta gönderimi, rapor oluşturma).
-
Mikroservisler arasında asenkron iş yükü tamponlama.
-
Ani trafik artışlarında istekleri kuyrukta bekletme .
Kritik Nokta: SQS, tüketicinin hızına saygı duyar. Yavaş bir tüketici, mesajları biriktirir ama kaybetmez. Ancak gecikme artar.
2. Amazon SNS: Pub/Sub ve Fan-Out (Push-Based)
SNS, bir mesajı birden fazla aboneye aynı anda ileten bir yayınla-abone ol (publish-subscribe) servisidir. Aboneler HTTP endpoint'leri, e-posta, SMS, Lambda fonksiyonları veya başka SQS kuyrukları olabilir .
Temel Özellikler:
-
Anlık Teslimat: Mesajlar kalıcı değildir; abonelere gerçek zamanlı iletilir .
-
Fan-Out: Tek bir olay, birden fazla bağımsız tüketiciye dağıtılabilir.
-
Mesaj Filtreleme: Abonelik filtre politikaları ile her abone yalnızca ilgilendiği mesajları alır .
-
Teslimat Garantisi: HTTP/S için at-least-once; Lambda ve SQS için exactly-once .
Ne Zaman Kullanılır?
-
Bir sipariş oluştuğunda ödeme, stok ve bildirim servislerini aynı anda tetiklemek (fan-out).
-
Mobil push bildirimleri, e-posta veya SMS gönderimi.
-
SQS ile birlikte kullanılarak "fan-out + buffer" deseni oluşturmak .
3. Amazon EventBridge: Olay Veriyolu (Event Bus)
EventBridge, olayları kurallara (rules) göre filtreleyip hedef servislere yönlendiren tam yönetilen bir olay veriyoludur. AWS servisleri, SaaS uygulamaları ve özel uygulamalar arasında olay paylaşımını sağlar .
Temel Özellikler:
-
İçerik Tabanlı Yönlendirme: Olayın içeriğine (ör.
total > 1000) göre farklı hedeflere yönlendirme yapılabilir . -
Gelişmiş Filtreleme: SNS'in basit filtrelerinden daha güçlü, JSON tabanlı desen eşleştirme sunar.
-
Sıralama Garantisi Yoktur: Olaylar hedeflere rastgele sırada iletilebilir .
-
Otomatik Yeniden Deneme: Başarısız teslimatlar için 24 saate kadar üstel geri çekilme ile yeniden dener .
Ne Zaman Kullanılır?
-
AWS servisleri arasında olay yönlendirme (S3'e dosya yüklendiğinde Lambda tetikleme).
-
Karmaşık iş kurallarına göre olay filtreleme.
-
Farklı hesaplar arasında olay paylaşımı (cross-account).
-
SaaS entegrasyonları (PagerDuty, Datadog, New Relic) .
4. Karşılaştırma Tablosu
| Kriter | SQS | SNS | EventBridge |
|---|---|---|---|
| Model | Pull (tüketici çeker) | Push (aboneye iter) | Event-driven (kural eşleştirir) |
| Kalıcılık | Var (14 güne kadar) | Yok (gerçek zamanlı) | Yok (gerçek zamanlı) |
| Sıralama | FIFO ile garanti | FIFO ile garanti | Garanti yok |
| Filtreleme | Yok (SNS ile birlikte kullanılır) | Abonelik filtreleri | Gelişmiş içerik tabanlı |
| Tipik Kullanım | İş kuyruğu, buffer | Fan-out, bildirim | Olay yönlendirme, entegrasyon |
5. Gerçek Dünya Deseni: Sipariş İşleme
En yaygın serverless desen, üç servisin birlikte kullanılmasıdır:
text
API Gateway → Lambda (Order Intake) → EventBridge (OrderPlaced)
↓
┌─────────────────────┼─────────────────────┐
↓ ↓ ↓
Lambda (Payment) Lambda (Inventory) SQS → Lambda (Notification)
Akış:
-
Sipariş API'ye gelir, Lambda DynamoDB'ye yazar ve EventBridge'e
OrderPlacedolayı yayınlar. -
EventBridge, aynı olayı üç bağımsız hedefe yönlendirir: ödeme, stok ve bildirim.
-
Bildirim servisi yavaş çalışıyorsa, SQS kuyruğu mesajları tamponlar; müşteri beklemez .
Bu desen, her servisin bağımsız ölçeklenmesini ve birindeki hatanın diğerlerini etkilememesini sağlar.
6. En İyi Pratikler
| Pratik | Açıklama |
|---|---|
| Idempotency Sağlayın | At-least-once teslimat nedeniyle aynı mesaj birden fazla gelebilir . |
| DLQ Kullanın | SQS ve SNS için Dead-Letter Queue yapılandırın; başarısız mesajları izole edin . |
| SQS + SNS Birlikte Kullanın | Fan-out gerekiyorsa SNS, buffer gerekiyorsa arkasına SQS ekleyin . |
| EventBridge'de Şema Kullanın | Olay şemalarını tanımlayın; farklı ekipler arasında sözleşme netliği sağlayın. |
| Sıralama Gerekiyorsa FIFO Seçin | SQS/SNS FIFO kullanın; EventBridge sıralama garanti etmez . |
Sonuç
SQS, SNS ve EventBridge, serverless olay tabanlı mimarilerin üç farklı ihtiyacına cevap verir: SQS güvenilir tamponlama ve asenkron iş kuyrukları için, SNS anlık fan-out ve bildirim dağıtımı için, EventBridge ise içerik tabanlı olay yönlendirme ve servis entegrasyonu için idealdir. Doğru desen, "mesaj bekletilmeli mi, dağıtılmalı mı, yoksa içeriğe göre mi yönlendirilmeli?" sorusunun cevabına bağlıdır. Çoğu üretim mimarisinde bu üç servis birlikte kullanılır; önemli olan her birinin rolünü netleştirmek ve idempotency, DLQ ve filtreleme gibi dayanıklılık pratiklerini uygulamaktır.