SQS #

Dalam arsitektur sistem modern—terutama yang mengadopsi microservices, event-driven architecture, dan serverless—kebutuhan akan komunikasi antar komponen yang loosely coupled, reliable, dan scalable menjadi sangat krusial. AWS Simple Queue Service (SQS) hadir sebagai salah satu fondasi utama untuk menyelesaikan problem tersebut.

Artikel ini akan membahas AWS SQS secara menyeluruh dan praktis: mulai dari apa itu SQS, mengapa ia dikategorikan sebagai serverless, jenis-jenis queue yang tersedia, opsi konfigurasi penting, aspek monitoring, hingga best practice di dunia nyata.

Apa Itu AWS SQS? #

AWS Simple Queue Service (SQS) adalah layanan fully managed message queue dari AWS yang memungkinkan komponen aplikasi saling berkomunikasi secara asynchronous dengan cara mengirim dan menerima pesan melalui sebuah queue.

Karakteristik utama SQS:

Fully managed (tanpa perlu mengelola server atau broker)
Highly available dan durable
Scalable secara otomatis
Mendukung at-least-once delivery

Secara konseptual:

Producer mengirim pesan ke queue
Consumer mengambil dan memproses pesan dari queue
Producer dan consumer tidak perlu saling mengetahui secara langsung

Hal ini membuat SQS sangat cocok untuk:

Decoupling antar service
Buffering traffic spike
Retry mekanisme alami
Background / async processing

Kenapa AWS SQS Disebut Serverless? #

AWS SQS dikategorikan sebagai serverless service karena:

Tidak Ada Infrastruktur yang Dikelola User
- Tidak perlu provisioning server
- Tidak ada patching, scaling, atau HA setup
Auto Scaling Transparan
- Jumlah message bisa naik/turun tanpa konfigurasi kapasitas
Pay-as-you-go
- Biaya berdasarkan jumlah request dan data transfer
Integrasi Native dengan Serverless Stack
- Lambda, EventBridge, SNS, Step Functions

Dengan kata lain, SQS fokus pada logic komunikasi, bukan operasional message broker.

Jenis-Jenis Queue di AWS SQS #

AWS SQS menyediakan dua tipe queue utama dengan trade-off yang jelas.

Standard Queue #

Karakteristik:

At-least-once delivery
Best-effort ordering (tidak menjamin urutan)
Throughput hampir tidak terbatas

Kelebihan:

Sangat scalable
Cocok untuk high-throughput workload

Kekurangan:

Pesan bisa diproses lebih dari sekali
Urutan pesan tidak dijamin

Use case umum:

Event processing
Log ingestion
Background jobs besar

FIFO Queue #

Karakteristik:

Exactly-once processing (deduplication)
Strict ordering (First In First Out)
Throughput lebih terbatas dibanding Standard

Konsep penting:

MessageGroupId → menjamin ordering dalam satu grup
DeduplicationId → mencegah duplicate message

Use case umum:

Transaksi finansial
Order processing
Workflow yang sensitif terhadap urutan

Konfigurasi Penting di AWS SQS #

Berikut konfigurasi-konfigurasi krusial yang wajib dipahami sebelum menggunakan SQS di production.

Visibility Timeout #

Waktu di mana pesan disembunyikan sementara setelah di-receive oleh consumer.

Jika consumer gagal memproses sebelum timeout → pesan muncul kembali
Harus lebih besar dari rata-rata waktu processing

Anti-pattern:

Visibility timeout terlalu pendek → duplicate processing

Message Retention Period #

Berapa lama pesan disimpan di queue jika belum diproses.

Default: 4 hari
Maksimum: 14 hari

Gunakan retention panjang jika:

Ada potensi consumer down lama
Perlu reprocessing manual

Delivery Delay #

Menunda pesan agar tidak langsung tersedia.

Use case:

Scheduled job sederhana
Cool-down period

Catatan:

Bukan pengganti scheduler kompleks

Receive Message Wait Time (Long Polling) #

Mengurangi empty response saat queue kosong.

Nilai 0 → short polling
Nilai 1–20 detik → long polling

Best practice:

Selalu gunakan long polling (≥10 detik)

Dead Letter Queue (DLQ) #

Queue khusus untuk pesan yang gagal diproses berkali-kali.

Konfigurasi utama:

maxReceiveCount

Manfaat DLQ:

Isolasi pesan bermasalah
Debugging & replay
Stabilitas sistem utama

Encryption #

SSE-SQS (AWS-managed key)
SSE-KMS (customer-managed key)

Gunakan KMS jika:

Compliance tinggi
Audit trail diperlukan

Apa Saja yang Bisa Dimonitor dari SQS? #

Monitoring SQS dilakukan terutama via Amazon CloudWatch.

Metric Penting #

ApproximateNumberOfMessagesVisible
- Jumlah pesan siap diproses
- Indikator backlog
ApproximateNumberOfMessagesNotVisible
- Pesan sedang diproses
NumberOfMessagesSent / Received / Deleted
- Throughput queue
ApproximateAgeOfOldestMessage
- SLA latency
- Alarm wajib di production
NumberOfMessagesMovedToDLQ
- Indikasi error logic

Alarm yang Disarankan #

Oldest message age > SLA
DLQ message count > 0
Backlog meningkat terus

Integrasi Umum AWS SQS #

SQS sering digunakan bersama:

AWS Lambda → event-driven consumer
SNS → SQS → fan-out pattern
EventBridge → event routing
ECS / EKS → worker pool
Step Functions → orchestration

Pros dan Cons AWS SQS #

✅ Pros (Kelebihan) #

Fully Managed & Serverless Tidak perlu mengelola server, broker, scaling, patching, maupun high availability. Tim bisa fokus ke business logic.
Highly Scalable & Reliable SQS mampu menangani lonjakan traffic besar secara otomatis dengan durabilitas tinggi (multi-AZ by default).
Loose Coupling Antar Service Producer dan consumer tidak saling bergantung langsung, meningkatkan resilience dan fleksibilitas arsitektur.
Integrasi Native dengan Ekosistem AWS Terintegrasi secara mulus dengan Lambda, SNS, EventBridge, ECS, EKS, dan Step Functions.
Pay-as-you-go Biaya berdasarkan jumlah request, tanpa biaya idle resource.
Built-in Retry Mechanism Retry terjadi secara natural melalui visibility timeout tanpa perlu logic kompleks di aplikasi.
Dead Letter Queue (DLQ) Native Mendukung isolasi pesan bermasalah untuk debugging dan replay.

❌ Cons (Kekurangan & Limitasi) #

At-least-once Delivery (Standard Queue) Pesan bisa diproses lebih dari sekali, sehingga consumer wajib idempotent.
Ordering Tidak Dijamin (Standard Queue) Tidak cocok untuk workflow yang sangat sensitif terhadap urutan pesan.
FIFO Queue Lebih Mahal & Throughput Terbatas FIFO memiliki batas throughput dan biaya lebih tinggi dibanding Standard Queue.
Bukan Message Streaming Platform Tidak mendukung replay message kompleks, offset management, atau consumer group seperti Kafka.
Delay & Scheduling Terbatas Delivery delay maksimum 15 menit — bukan pengganti scheduler atau workflow engine.
Observability Terbatas di Level Message Tidak bisa melihat isi message secara detail tanpa consumer tambahan.
Potensi Hidden Cost Jika Salah Desain
- Polling berlebihan
- Visibility timeout salah
- Retry tak terkendali

Kapan AWS SQS Bukan Pilihan Tepat? #

Butuh exactly-once + ordering global skala besar → Kafka
Butuh message replay kompleks → Kafka / Kinesis
Butuh query ke message → bukan domain SQS

Best Practice #

Selalu Anggap Pesan Bisa Duplicate #

Walaupun FIFO mendukung deduplication, logic consumer harus idempotent.

Gunakan DLQ Sejak Awal #

Jangan menunggu error terjadi di production.

Sesuaikan Visibility Timeout dengan Real Processing Time #

Gunakan metric nyata, bukan asumsi.

Batasi Concurrency Consumer #

Lambda: atur reserved concurrency
ECS/EKS: worker limit

Tujuan: hindari thundering herd.

Jangan Gunakan SQS sebagai Database #

SQS adalah buffer komunikasi, bukan storage permanen.

Gunakan FIFO Hanya Jika Benar-Benar Perlu #

FIFO lebih mahal dan throughput terbatas.

Pisahkan Queue Berdasarkan Concern #

Satu queue untuk satu jenis event
Hindari overloading satu queue

Penutup #

AWS SQS adalah building block fundamental dalam arsitektur serverless dan distributed system di AWS. Dengan pemahaman yang benar terhadap jenis queue, konfigurasi, monitoring, dan best practice, SQS dapat menjadi solusi yang sederhana namun sangat powerful.

Kesalahan umum bukan pada SQS-nya, melainkan pada:

Salah memilih tipe queue
Salah konfigurasi visibility timeout
Tidak menyiapkan DLQ
Consumer logic yang tidak idempotent

Jika digunakan dengan tepat, SQS mampu meningkatkan resilience, scalability, dan maintainability sistem secara signifikan.