Belajar Floci - SQS & SNS Emulation

#Pendahuluan

Arsitektur event-driven adalah pola dominan sistem AWS-native modern — dan dua layanan messaging intinya adalah SQS (queue) dan SNS (pub/sub). Keduanya juga area di mana emulator lokal memberikan nilai paling terasa: tanpa emulator, menguji retry, DLQ, dan fan-out butuh environment cloud sungguhan dan banyak kesabaran.

Episode ini membahas cakupan emulasi keduanya di Floci, lalu menyatukannya dalam pipeline order-event yang menjadi fondasi arsitektur microservice di sisa series.

#SQS

#Standard & FIFO Queue

Buat standard & FIFO queue

aws --endpoint-url=http://localhost:4566 sqs create-queue --queue-name orders
aws --endpoint-url=http://localhost:4566 sqs create-queue \
  --queue-name payments.fifo \
  --attributes '{"FifoQueue":"true","ContentBasedDeduplication":"true"}'

Standard queue menawarkan throughput maksimal dengan at-least-once delivery; FIFO menambah deduplication dan ordering via MessageGroupId. Perilaku dasar keduanya ditiru Floci — termasuk validasi akhiran .fifo yang wajib konsisten.

#Visibility Timeout & Dead-Letter Queue

Dua mekanisme reliability terpenting:

Visibility + DLQ

# Pesan gagal diproses -> muncul lagi setelah visibility timeout berakhir
aws --endpoint-url=http://localhost:4566 sqs receive-message \
  --queue-url http://localhost:4566/000000000000/orders \
  --visibility-timeout 30
 
# Rantai DLQ: setelah maxReceiveCount, pesan dipindah otomatis
aws --endpoint-url=http://localhost:4566 sqs create-queue --queue-name orders-dlq
aws --endpoint-url=http://localhost:4566 sqs set-queue-attributes \
  --queue-url http://localhost:4566/000000000000/orders \
  --attributes '{"RedrivePolicy":"{\"deadLetterTargetArn\":\"arn:aws:sqs:us-east-1:000000000000:orders-dlq\",\"maxReceiveCount\":3}"}'

Simulasi klasik untuk diuji: consumer yang selalu gagal → lihat pesan muncul kembali tiap visibility timeout → setelah 3x receive, otomatis pindah ke orders-dlq. Ini test yang sulit dan mahal dilakukan di AWS asli; di lokal ia selesai dalam hitungan detik.

#SNS

Topic + subscription

TOPIC_ARN=$(aws --endpoint-url=http://localhost:4566 sns create-topic \
  --name order-events --query TopicArn --output text)
 
aws --endpoint-url=http://localhost:4566 sns subscribe \
  --topic-arn "$TOPIC_ARN" \
  --protocol sqs \
  --notification-endpoint arn:aws:sqs:us-east-1:000000000000:orders
 
# Message filtering: hanya event tertentu yang masuk queue ini
aws --endpoint-url=http://localhost:4566 sns set-subscription-attributes \
  --subscription-arn "$SUB_ARN" \
  --attribute-name FilterPolicy \
  --attribute-value '{"event_type":["order.created","order.paid"]}'

Tipe subscription yang didukung mencakup SQS (fan-out utama), Lambda (langsung memicu fungsi — episode 7), dan http endpoint lokal. Filter policy dievaluasi terhadap atribut message body JSON seperti aslinya.

#Praktik

Target outline: pipeline order-event — publish SNS → fan-out SQS → consumer.

set -euo pipefail
export AWS_ENDPOINT_URL=http://localhost:4566
 
aws sqs create-queue --queue-name billing >/dev/null
aws sqs create-queue --queue-name shipping >/dev/null
TOPIC=$(aws sns create-topic --name order-events --query TopicArn --output text)
 
for q in billing shipping; do
  aws sns subscribe --topic-arn "$TOPIC" --protocol sqs \
    --notification-endpoint "arn:aws:sqs:us-east-1:000000000000:$q" >/dev/null
done
 
aws sns publish --topic-arn "$TOPIC" \
  --message '{"order_id":"ORD-1","event_type":"order.created","total":250000}' >/dev/null
echo "event published -> fan-out ke 2 queue"

import boto3
 
sqs = boto3.client("sqs", endpoint_url="http://localhost:4566")
url = sqs.get_queue_url(QueueName="billing")["QueueUrl"]
 
resp = sqs.receive_message(QueueUrl=url, MaxNumberOfMessages=5)
msgs = resp.get("Messages", [])
assert msgs and msgs[0]["Body"].startswith('{"Type":"Notification"'), "envelope SNS tidak diterima"
print("billing consumer menerima:", msgs[0]["Body"])
sqs.delete_message(QueueUrl=url, ReceiptHandle=msgs[0]["ReceiptHandle"])

Detail penting yang justru bernilai parity: saat SNS mengirim ke SQS, body yang diterima consumer adalah envelope notifikasi (Type, Message, TopicArn) — bukan payload mentah. Aplikasi produksi harus unwrap envelope; karena Floci meniru perilaku ini persis, bug integrasi semacam ini ketahuan di lokal, bukan di staging.

Tip

Tambahkan RawMessageDelivery: "true" pada subscription attributes bila ingin payload langsung tanpa envelope — dan uji kedua mode, karena library deserialisasi tim kalian bisa sensitif terhadapnya.

#Penutup

Rangkuman episode ini:

SQS: standard & FIFO, visibility timeout, RedrivePolicy/DLQ dengan maxReceiveCount — semua bisa disimulasikan cepat.
SNS: topic + subscribe ke SQS/Lambda/http, filter policy per-subscription.
Pipeline order-event end-to-end; perhatian pada envelope notifikasi vs raw delivery.

Episode 7 masuk bintang utama serverless: emulasi Lambda — create/invoke fungsi, event sources dari SQS/SNS/S3, layers, dan perilaku cold start. Sampai jumpa!