SQL Maxis: Mengapa RabbitMQ Diganti dengan Queue Postgres

• RabbitMQ disingkirkan dan diganti dengan queue berbasis SQL di PostgresDB
• Penggantian ini memakan waktu sekitar setengah hari, dan source code berkurang 580 baris
• Yang jauh lebih penting, stabilitas dan ketahanan (resiliency) meningkat secara signifikan
• Ini bukan cerita tentang masalah pada sistem queue seperti RabbitMQ, melainkan bagian dari upaya untuk menjaga semuanya tetap sederhana
  • Prequel, yang menulis artikel ini, adalah produk yang membantu perusahaan B2B SaaS menyinkronkan database pelanggan mereka melalui pipeline data berskala besar
• Sebelumnya sistem disusun dengan RabbitMQ + AQMP + Helm + wrapper GoLang, dan sempat berjalan baik untuk beberapa waktu, tetapi kemudian masalah mulai muncul
  • Pengiriman pesan tertunda terlalu lama sehingga pesan dibatalkan
  • Saat consumer melakukan prefetch pada pesan, terjadi situasi di mana pesan berikutnya sudah ditahan sampai pesan saat ini selesai diproses
  • Jika prefetch ini diatur ke 0, nilainya justru menjadi tak terbatas, sehingga prefetch tidak bisa dinonaktifkan
  • Masalah ini muncul karena pekerjaan yang menerima dan memproses pesan umumnya adalah pekerjaan jangka panjang (transfer data)
• Mereka akhirnya memahami dengan tepat apa yang terjadi, tetapi tidak ada cara untuk segera memperbaikinya. Karena masalah ini terjadi pada pelanggan production, menunggu bukan pilihan
• Karena itu, mereka beralih ke pendekatan baca/tulis menggunakan satu tabel sederhana di Postgres
  • Lock row-level untuk baca/tulis digunakan agar hanya satu consumer yang dapat membaca pekerjaan
  • Sangat sederhana sampai terasa konyol, tetapi bekerja dengan sempurna
• Keuntungannya, status aplikasi tidak lagi terpecah antara RabbitMQ dan Postgres, melainkan terpusat dalam satu tempat

[galadbran]

Saya juga mengimplementasikan queue sendiri di MySQL dengan row level lock, dan sudah berjalan dengan baik di produk selama bertahun-tahun.
Saya hanya menginginkan sesuatu yang bisa menyediakan fungsi mirip queue untuk beberapa worker, sekaligus menyimpan payload beserta status menunggu/berjalan/gagal di dalam queue (jika selesai maka dihapus).

Melihat dari isi artikelnya, mereka memindahkan dari RabbitMQ ke database dalam waktu singkat, jadi saya rasa itu mungkin karena mereka memang tidak membutuhkan fleksibilitas umum, beragam fitur, dan opsi konfigurasi yang ditawarkan layanan queue khusus terpisah.

[pseudojo]

Sepertinya masalah muncul karena ada celah antara pengiriman ACK manual dan transaksi DB,
menarik karena mereka menyelesaikannya bukan lewat rekayasa, melainkan dengan menyingkirkan RabbitMQ.
Padahal RabbitMQ sendiri sepertinya tidak salah...

[laracool]

https://news.ycombinator.com/item?id=35526846
Ada banyak pendapat di komentar.

[dddddd]

Sepertinya ada juga yang seperti ini dan bekerja dengan cara yang mirip: https://github.com/pjongy/jasyncq

[laracool]

Sepertinya ada kemungkinan baris yang sama akan di-select secara bersamaan; saya penasaran bagaimana hal itu diselesaikan.

[dddddd]

Sepertinya tertulis row level lock.