Komunitas teknologi sedang ramai membicarakan cerita tentang implementasi message queue yang tidak konvensional, dipicu oleh diskusi seputar solusi engineering yang kreatif. Meskipun message queue tradisional seperti Amazon SQS atau Apache Kafka adalah pilihan standar, developer telah menemukan alternatif yang mengejutkan efektif di tempat-tempat yang paling tidak terduga.
Email Server sebagai Message Queue
Salah satu contoh paling menarik berasal dari startup tahun 1990-an yang tidak mampu membeli solusi messaging enterprise yang mahal. Tim tersebut beralih menggunakan Microsoft Exchange Server sebagai sistem message queue mereka. Message producer menggunakan library SMTP untuk mengirim email, sementara consumer menggunakan Exchange API untuk membaca pesan yang belum dibaca. Mereka menandai pesan sebagai sudah dibaca selama pemrosesan dan memindahkan tugas yang selesai ke folder yang berbeda. Solusi kreatif ini bekerja dengan sangat baik selama lima tahun, menawarkan inspeksi queue yang mudah melalui klien email standar dan bahkan memungkinkan manusia menangani queue tertentu saat dibutuhkan.
SMTP (Simple Mail Transfer Protocol) adalah protokol standar untuk mengirim email, sementara API (Application Programming Interface) adalah seperangkat alat yang memungkinkan program perangkat lunak berbeda untuk berkomunikasi satu sama lain.
Contoh Message Queue Kreatif:
- Server email ( Microsoft Exchange dengan SMTP/APIs )
- Tabel database dengan SELECT FOR UPDATE SKIP LOCKED
- Bucket Amazon S3 (mahal dan tidak efisien)
- Repositori Git dengan webhooks
- Router jaringan dengan paket UDP
- Sistem file dan paket ping
Pelajaran Mahal Amazon dengan S3
Diskusi ini juga menyoroti kesalahan arsitektur terkenal Amazon Prime Video , di mana mereka menggunakan bucket storage Amazon S3 untuk menangani frame video individual untuk pemrosesan real-time. Pendekatan ini menciptakan biaya yang sangat besar karena tingginya jumlah permintaan storage dan mencapai batas layanan AWS . Tim tersebut akhirnya kembali ke arsitektur monolitik tradisional, menunjukkan bahwa bahkan raksasa teknologi dapat terjebak dalam perangkap over-engineering dengan layanan cloud.
Mereka benar-benar sangat terhanyut dengan serverless AWS jika mereka berpikir cara yang tepat untuk streaming video adalah beberapa microservice yang mengakses frame individual di S3 .
Tabel Database dan Protokol Jaringan
Banyak developer berbagi pengalaman dengan message queue berbasis database menggunakan perintah SQL seperti SELECT FOR UPDATE SKIP LOCKED untuk mencegah pemrosesan duplikat. Meskipun ini bekerja untuk aplikasi yang lebih kecil, sering kali rusak di bawah lalu lintas tinggi karena masalah locking dan race condition. Beberapa bahkan mengusulkan menggunakan router jaringan dan paket UDP sebagai sistem pengiriman pesan throughput tinggi, meskipun pendekatan ini mengorbankan jaminan pengiriman demi kecepatan.
UDP (User Datagram Protocol) adalah protokol jaringan yang mengirim data dengan cepat tetapi tidak menjamin bahwa semua pesan akan tiba atau tiba dalam urutan yang benar.
Repository Git dan Seterusnya
Mungkin solusi paling kreatif melibatkan penggunaan repository GitLab dengan webhook sebagai sistem event berqueue. Perubahan akan memicu webhook yang menambahkan data ke file JSON , melakukan commit perubahan, dan memicu proses downstream. Meskipun digambarkan sebagai mengerikan dan mulia, ini menunjukkan sejauh mana developer akan berusaha memecahkan masalah dengan alat yang tersedia.
Pertukaran Utama:
- Biaya: Solusi kreatif seringkali lebih murah pada awalnya
- Keandalan: Queue yang dibuat khusus menawarkan jaminan yang lebih baik
- Skalabilitas: Queue tradisional menangani lalu lintas tinggi dengan lebih baik
- Fitur: Dead letter queue bawaan, metrik, logika percobaan ulang
- Pemeliharaan: Solusi kustom memerlukan lebih banyak pekerjaan berkelanjutan
 |
|---|
| Karakter yang siap beraksi mewakili pola pikir pemecahan masalah kreatif yang diperlukan ketika menggunakan metode tidak konvensional seperti GitLab sebagai antrian pesan |
Pelajaran dalam Engineering Kreatif
Cerita-cerita ini menyoroti prinsip penting dalam pengembangan perangkat lunak: terkadang solusi terbaik bukanlah yang paling jelas. Meskipun message queue yang dibuat khusus menawarkan keandalan dan fitur seperti dead letter queue dan automatic scaling, alternatif kreatif dapat bekerja dengan sangat baik untuk kasus penggunaan tertentu. Kuncinya adalah memahami trade-off antara biaya, kompleksitas, dan persyaratan.
Namun, seperti yang dicatat oleh salah satu anggota komunitas, membuat message queue sendiri sering kali mengarah pada penemuan kembali roda, dengan buruk. Layanan modern seperti Amazon SQS menangani manajemen state kompleks yang membuat message queue dapat diandalkan, termasuk fitur seperti message visibility timeout dan mekanisme retry otomatis.
Referensi: Anything can be a message queue if you use it wrongly enough