SNS #

Dalam arsitektur sistem terdistribusi modern yang menerapkan pola microservices dan event-driven, salah satu kebutuhan yang paling sering muncul adalah mendistribusikan satu kejadian (event) ke banyak layanan penerima yang berbeda secara bersamaan. Sebagai contoh, ketika seorang pengguna berhasil melakukan transaksi pembelian (event: OrderCreated), sistem harus segera mengabari layanan inventaris untuk memotong stok, memberi tahu layanan pembayaran untuk memproses kartu kredit, dan memicu layanan notifikasi untuk mengirimkan tanda terima transaksi ke email pengguna.

Jika kita menghubungkan layanan-layanan tersebut secara sinkron satu per satu melalui panggilan HTTP, sistem kita akan menjadi sangat kaku, lambat, dan rentan terhadap kegagalan. Di sinilah AWS Simple Notification Service (SNS) mengambil peran vital. Sebagai layanan publish-subscribe (pub/sub) berbasis serverless yang dikelola penuh (fully managed), SNS memungkinkan kita menyiarkan (broadcast) pesan ke banyak konsumen secara asinkron dengan latensi rendah dan skala global.

Apa itu AWS SNS? #

AWS Simple Notification Service (SNS) adalah layanan pengiriman pesan berbasis model Publish-Subscribe (Pub/Sub).

Di dalam model ini, pengirim pesan dan penerima pesan dipisahkan secara struktural melalui perantara bernama Topic:

Publisher: Komponen pengirim yang mempublikasikan pesan ke topik SNS tertentu. Publisher tidak perlu mengetahui siapa saja, di mana, atau ada berapa banyak penerima yang mendengarkan topik tersebut.
Topic: Titik komunikasi logis di mana pesan dikirimkan. Topik bertindak sebagai saluran distribusi.
Subscriber / Consumer: Endpoint yang berlangganan (subscribe) ke topik SNS tersebut. Ketika sebuah pesan baru masuk ke topik, SNS akan menduplikasi dan mendorong (push) pesan tersebut ke seluruh subscriber yang terdaftar secara instan.

flowchart TD
    Producer["Layanan Order (Lambda)"] -->|Publish Event: order-created| Topic["AWS SNS Topic<br/>'order-created'"]
    
    Topic -->|Rute Langsung| LambdaEmail["Layanan Email (Lambda)"]
    
    Topic -->|Filter: status = VIP| SQSVIP["Antrean SQS VIP (FIFO)"]
    SQSVIP --> WorkerVIP["Worker VIP (Fargate)"]
    
    Topic -->|Filter: status = Regular| SQSReg["Antrean SQS Regular"]
    SQSReg --> WorkerReg["Worker Regular (Fargate)"]
    
    Topic -->|Kirim ke HTTP End-point| Webhook["Situs Pihak Ketiga (Webhook)"]

Meskipun keduanya adalah layanan pesan serverless di AWS, SNS dan SQS dirancang untuk memecahkan masalah arsitektur yang bertolak belakang.

Kriteria Perbandingan	AWS SNS (Simple Notification Service)	AWS SQS (Simple Queue Service)
Model Komunikasi	Publish-Subscribe (Pub/Sub)	Point-to-Point (Queue)
Metode Pengiriman	Push Model (SNS langsung mengirimkan pesan ke subscriber)	Pull Model (Consumer secara aktif melakukan polling pesan)
Penerima Pesan	Banyak (One-to-Many / Fan-out)	Satu (One-to-One / Work Queue)
Daya Tahan Pesan	Ephemeral (Pesan langsung dibuang setelah sukses dikirim)	Durable (Pesan disimpan di antrean hingga 14 hari)
Urutan Pesan	Tidak dijamin (Tersedia FIFO dengan batasan throughput)	FIFO tersedia dengan opsi strict ordering
Use Case Utama	Broadcast event, notifikasi multi-channel, alert sistem	Pemrosesan tugas, load leveling, background jobs

Jenis-Jenis Subscription (Penerima) yang Didukung #

AWS SNS sangat fleksibel karena mendukung pengiriman pesan ke berbagai jenis protokol endpoint:

Amazon SQS: Mengirimkan pesan SNS ke antrean SQS. Ini adalah pola arsitektur Fan-out paling populer untuk memastikan durabilitas pesan dan pemrosesan asinkron yang andal.
AWS Lambda: Memicu fungsi Lambda secara instan untuk mengeksekusi logika serverless saat ada pesan masuk.
HTTP / HTTPS: Mengirimkan pesan sebagai request HTTP POST (Webhook) ke server web eksternal di luar lingkungan AWS.
Email / Email-JSON: Mengirimkan isi pesan langsung ke kotak masuk email pengguna dalam format teks biasa atau format JSON terstruktur.
SMS (Short Message Service): Mengirimkan pesan teks langsung ke nomor telepon seluler di lebih dari 200 negara untuk kebutuhan verifikasi OTP atau peringatan kritis.
Mobile Push Notifications: Mengirimkan notifikasi langsung ke aplikasi mobile iOS, Android, macOS, atau Windows menggunakan platform Firebase Cloud Messaging (FCM) atau Apple Push Notification service (APNs).

Fitur Canggih: Message Filtering #

Secara default, seluruh subscriber yang terdaftar pada sebuah topik SNS akan menerima salinan dari setiap pesan yang dikirimkan ke topik tersebut. Namun, sering kali kita ingin agar subscriber tertentu hanya menerima pesan yang relevan bagi mereka. Fitur Subscription Filter Policies memungkinkan kita menyaring pesan di tingkat SNS sebelum dikirimkan ke subscriber, sehingga menghemat biaya komputasi dan bandwidth di sisi consumer.

Cara Kerja Saringan (Filtering) #

Publisher menyertakan metadata tambahan yang disebut Message Attributes saat mengirimkan pesan ke topik. Subscriber mendefinisikan aturan penyaringan (filter policy) dalam format dokumen JSON.

Contoh JSON Kebijakan Filter di Subscriber: #

Misalkan kita memiliki antrean SQS khusus untuk memproses pengiriman barang VIP. Kita dapat memasang kebijakan filter berikut pada langganan SQS tersebut ke topik SNS order-created:

{
  "store": ["singapore", "jakarta"],
  "order_value": [{"numeric": [">=", 1000000]}],
  "customer_type": ["VIP"]
}

Dengan filter policy di atas, SQS VIP ini hanya akan menerima pesan jika pesannya dikirim dari toko di Singapore atau Jakarta, memiliki nilai belanja minimal Rp 1.000.000, dan tipe pelanggannya adalah VIP. Semua pesan lain yang tidak memenuhi kriteria tersebut akan dibuang secara otomatis oleh SNS tanpa dikirim ke SQS VIP tersebut.

Contoh Implementasi Praktis: Node.js #

Berikut adalah contoh penulisan kode menggunakan AWS SDK v3 untuk Node.js untuk mempublikasikan pesan ke topik SNS, lengkap dengan penyertaan Message Attributes untuk kebutuhan filter policy.

import { SNSClient, PublishCommand } from "@aws-sdk/client-sns";

// Inisiasi client SNS
const snsClient = new SNSClient({ region: "ap-southeast-1" });
const TOPIC_ARN = process.env.SNS_TOPIC_ARN;

export const handler = async (event) => {
    try {
        const orderPayload = {
            orderId: "ORD-77621",
            items: ["Laptop", "Mouse"],
            total: 12500000
        };

        // Konfigurasi perintah publish
        const command = new PublishCommand({
            TopicArn: TOPIC_ARN,
            // Konten pesan utama wajib bertipe String (biasanya JSON stringified)
            Message: JSON.stringify(orderPayload),
            Subject: "Transaksi Baru Dibuat",
            // ✓ Menyertakan Message Attributes untuk kebutuhan filtering di tingkat subscriber
            MessageAttributes: {
                "customer_type": {
                    DataType: "String",
                    StringValue: "VIP"
                },
                "order_value": {
                    DataType: "Number",
                    StringValue: "12500000"
                },
                "store": {
                    DataType: "String",
                    StringValue: "jakarta"
                }
            }
        });

        // Kirim pesan ke topik SNS
        const response = await snsClient.send(command);
        console.log(`Sukses publish pesan ke SNS. MessageId: ${response.MessageId}`);

        return {
            statusCode: 200,
            body: JSON.stringify({
                success: true,
                messageId: response.MessageId
            })
        };

    } catch (error) {
        console.error("Gagal melakukan publish ke SNS", error);
        return {
            statusCode: 500,
            body: JSON.stringify({ error: error.message })
        };
    }
};

Praktik Terbaik dalam Penggunaan SNS #

Untuk memastikan keandalan pengiriman pesan asinkron menggunakan SNS, selalu terapkan beberapa aturan desain berikut:

1. Gunakan Pola Fan-out (SNS + SQS) untuk Durabilitas Sistem #

Jika kita ingin memicu proses backend asinkron dari pesan SNS, jangan hubungkan SNS langsung ke fungsi Lambda jika performa dan keandalan data sangat kritis. Mengapa? Karena jika fungsi Lambda Anda mengalami throttling atau gagal, request push dari SNS akan langsung terbuang setelah masa retry habis.

Pola yang direkomendasikan adalah SNS -> SQS -> Lambda. Topik SNS menyiarkan pesan ke antrean SQS, dan antrean SQS bertindak sebagai buffer tahan lama yang akan menyimpan pesan secara aman sampai fungsi Lambda siap memprosesnya kembali.

2. Selalu Konfigurasi Dead Letter Queue (DLQ) pada Subscription #

Sama seperti SQS, langganan (subscription) SNS juga mendukung Dead Letter Queue (DLQ). Jika SNS gagal mengirimkan pesan ke endpoint tujuan (misalnya webhook HTTP target sedang down) setelah berulang kali mencoba kembali sesuai dengan kebijakan retry (delivery retry policy), SNS akan memindahkan pesan tersebut ke antrean SQS DLQ yang ditunjuk. Ini mempermudah pelacakan data yang gagal kirim.

Ringkasan #

AWS SNS adalah layanan messaging pub/sub serverless yang berfungsi menyiarkan (broadcast) pesan dari publisher ke banyak subscriber secara asinkron.

Mendukung arsitektur Fan-out (SNS + SQS) yang memisahkan dependensi antar-layanan secara tangguh tanpa risiko kehilangan pesan saat downstream down.

Subscription Filter Policies memungkinkan penyaringan pesan otomatis berbasis JSON di tingkat SNS menggunakan atribut pesan, sehingga menghemat komputasi consumer.

Mendukung multi-channel delivery, mulai dari pengiriman internal AWS (SQS, Lambda) hingga pengiriman publik eksternal (HTTP Webhooks, SMS, Email, Push Notif).

Terapkan DLQ (Dead Letter Queue) pada tingkat subscription untuk mendeteksi, mengisolasi, dan menganalisis pesan yang gagal dikirim karena masalah jaringan atau kegagalan sistem penerima.

← Sebelumnya: SQS Berikutnya: Step Functions →