Belajar Cloud Engineer - Message Queues & Streaming

#Pendahuluan

Di episode 12 kita memecah aplikasi menjadi microservices yang saling memanggil. Masalahnya: komunikasi synchronous (request-response) itu rapuh — jika service notifications sedang lambat, seluruh request checkout ikut lambat; jika notifications down, checkout ikut gagal. Solusinya adalah decoupling: jangan panggil langsung, tapi kirim pesan.

Episode 13 membahas message queues & streaming — SQS/SNS (AWS), Pub/Sub (GCP), Kinesis/Event Hubs/Event Streaming (Azure) — dan membangun event-driven pipeline: sistem di mana komponen saling bertukar peristiwa secara asynchronous, tahan gagal, dan bisa di-scale independen.

#Konsep Dasar: Message Broker dan Event Streaming

Ada dua pola besar yang sering tertukar:

• Queue: satu pesan, satu konsumen (pemrosesan selesai → pesan dihapus). Contoh: batch email, resize image.
• Topic: satu pesan, banyak penerima. Contoh: event "user.created" memicu email + analytics + audit.
• Event stream: aliran peristiwa yang disimpan berurutan dan bisa di-replay. Contoh: log klik user yang dianalisis.

#SQS dan SNS (AWS)

#SQS — Simple Queue Service

Antrian pesan terkelola. Pola paling umum: service web mengirim pesan, worker (Lambda atau VM) memproses.

QUEUE_URL=$(aws sqs create-queue --queue-name orders-queue \
  --query QueueUrl --output text)
 
aws sqs send-message --queue-url "$QUEUE_URL" \
  --message-body '{"orderId": "A-001", "items": 3}'
 
aws sqs receive-message --queue-url "$QUEUE_URL" \
  --max-number-of-messages 10

Konsep penting yang wajib dipahami:

• Visibility timeout — setelah pesan diterima, pesan "disembunyikan" dari konsumen lain selama X detik; jika worker selesai, pesan dihapus; jika tidak, pesan kembali ke antrian.
• Dead-letter queue (DLQ) — antrian khusus untuk pesan yang gagal diproses berkali-kali. Tanpa DLQ, pesan rusak akan membuat loop tanpa akhir.

aws sqs create-queue --queue-name orders-dlq
aws sqs set-queue-attributes --queue-url "$QUEUE_URL" \
  --attributes '{
    "RedrivePolicy": "{\"deadLetterTargetArn\":\"arn:aws:sqs:...:orders-dlq\",\"maxReceiveCount\":3}"
  }'

#SNS — Simple Notification Service

Fan-out: satu event, banyak penerima. Contoh: order.created dikirim ke SNS topic, lalu diterima SQS (untuk diproses Lambda), Lambda lain (untuk email), dan webhook eksternal.

TOPIC_ARN=$(aws sns create-topic --name order-events --query TopicArn --output text)
aws sns subscribe --topic-arn "$TOPIC_ARN" \
  --protocol sqs --notification-endpoint "$QUEUE_URL"
aws sns publish --topic-arn "$TOPIC_ARN" \
  --message '{"orderId": "A-002"}'

#GCP Pub/Sub dan Azure

#Pub/Sub (GCP)

Modelnya hampir identik dengan SNS+SQS dalam satu produk:

gcloud pubsub topics create order-events
gcloud pubsub subscriptions create order-workers \
  --topic=order-events --ack-deadline=60
gcloud pubsub topics publish order-events \
  --message='{"orderId":"A-003"}'
gcloud pubsub subscriptions pull order-workers --limit=10

Perbedaan penting: Pub/Sub tidak punya "visibility timeout" tapi ack deadline (waktu untuk mengakui pesan) — konsepnya sama: jika tidak di-ack dalam deadline, pesan dikirim ulang.

#Azure Service Bus dan Event Hubs

• Service Bus — queue/topic untuk aplikasi bisnis (pola SQS/SNS), dengan fitur session dan transaction.
• Event Hubs — event streaming untuk data besar (pola Kinesis/Kafka).

az servicebus namespace create --name sb-lab-uniq \
  --resource-group rg-lab --location southeastasia
az servicebus queue create --namespace-name sb-lab-uniq \
  --resource-group rg-lab --name orders-queue

#Event Streaming: Kinesis / Event Hubs

Ketika kebutuhan naik dari "kirim pesan" ke "aliran data yang dianalisis" — log, telemetri, klik user — event stream adalah jawabannya. Amazon Kinesis dan Azure Event Hubs menyimpan peristiwa secara berurutan, memungkinkan:

• Replay — memproses ulang data dari titik waktu tertentu.
• Multiple consumer groups — beberapa aplikasi membaca aliran yang sama secara independen.
• Throughput tinggi — ribuan peristiwa per detik.

aws kinesis create-stream --stream-name click-events \
  --shard-count 1
aws kinesis put-record \
  --stream-name click-events \
  --partition-key "user-123" \
  --data "$(echo '{"page":"/checkout"}' | base64)"

Mana yang dipilih: queue/topic untuk tugas aplikasi, event stream untuk analisis data. Jangan paksakan Kinesis untuk "kirim email" — itu pekerjaan SQS. Dan jangan pakai SQS untuk analisis — itu pekerjaan streaming.

#Membangun Event-Driven Pipeline

Mari bangun pipeline nyata: saat order dibuat, proses async berjalan.

Langkah:

1. Buat topic order-events dan tiga subscriber (dua queue + satu stream).
2. Publisher: API server mengirim event order.created — satu publish, tiga penerima.
3. Worker: setiap queue diproses Lambda/worker terpisah — jika satu lambat, yang lain tidak terpengaruh.
4. Uji ketahanan: matikan worker email, kirim order — order tetap sukses, pesan menunggu di queue, diproses setelah worker hidup kembali.

Inilah kekuatan decoupling: downstream tidak pernah menghalangi upstream. Sistem kalian menjadi tahan lonjakan (pesan mengantri) dan tahan kegagalan (worker bisa di-restart).

#Kesalahan Umum (Common Pitfalls)

1. Tidak pakai DLQ — pesan rusak loop selamanya dan menghabiskan resource.
2. Pesan diduplikasi — at-least-once delivery; konsumen harus idempotent (episode 11).
3. Pesan tanpa retry/delay — langsung gagal permanen padahal mungkin hanya butuh 5 menit.
4. Queue dipakai untuk streaming dan sebaliknya — pilih berdasarkan kebutuhan (1x-process vs replay).
5. Tidak memantau queue depth — antrian menumpuk tanpa alarm; metrik ApproximateNumberOfMessages wajib dimonitor (episode 9).

#Penutup

Inti yang harus dibawa pulang:

• Queue = satu pesan satu konsumen; topic = satu pesan banyak penerima; stream = aliran replayable.
• DLQ menyelamatkan pesan yang gagal; idempotency menyelamatkan dari duplikat.
• SNS+SQS, Pub/Sub, dan Service Bus adalah padanan antar-provider — konsepnya identik.
• Event streaming (Kinesis/Event Hubs) untuk analisis data, bukan untuk tugas aplikasi.
• Event-driven pipeline membuat sistem decoupled, tahan lonjakan, dan tahan gagal.

Di episode 14 selanjutnya kita akan membahas CI/CD di cloud — CodeBuild/Cloud Build/Azure DevOps, pipeline deployment ke VM, container, dan serverless — serta men-deploy aplikasi otomatis dari commit ke production. Sampai jumpa di episode 14!