Memilih Teknologi Queue Postgres

• Queue Postgres itu bagus, tetapi bukan arus utama karena ada anggapan umum bahwa teknologi queue lain menawarkan skalabilitas yang lebih besar
• Perusahaan seperti webapp.io memilih queue Postgres karena lebih mementingkan kesederhanaan operasional, kemudahan pemeliharaan, dan keakraban dibanding skalabilitas
• Komponen penyusun teknologi queue Postgres
  • Memberi tahu dan mendengarkan pekerjaan baru (pub/sub) serta saling-eksklusif (row locks)
  • Keduanya tersedia sejak Postgres 9.5 yang dirilis pada 2016
• Penulis membantah anggapan umum di industri bahwa menggunakan Postgres dengan cara ini bersifat "hacky", dan berargumen bahwa Postgres bukanlah teknologi queue kelas dua
• Redis, Apache Kafka, RabbitMQ, Amazon SQS, dan lainnya telah lama dipilih sebagai alat queue untuk menangani pekerjaan yang berjalan lama
• Penulis mengkritik obsesi industri teknologi terhadap "skala" dan pengorbanan atas kesederhanaan, kemudahan pemeliharaan, serta berkurangnya beban kognitif pengembang
• Saran penulis: saat membuat keputusan teknis, pertimbangkan teknologi yang saat ini sudah digunakan dan benar-benar dipahami dengan baik
• Penulis menganjurkan memilih "teknologi yang membosankan" yang sudah dipakai dan dipahami dengan baik
• Diperkenalkan konsep "membangun jalan keluar", yang berarti kode aplikasi untuk memproses pekerjaan seharusnya tidak bergantung pada queue
• Kesimpulannya, penulis mendorong orang lain untuk mempertimbangkan teknologi queue Postgres dan menjadikan "teknologi yang membosankan" sebagai pilihan default

[GN⁺]

Opini Hacker News

• Kesederhanaan, ketahanan, dan toleransi kegagalan Kafka memang diakui, tetapi sifatnya yang terdistribusi dapat menambah kompleksitas untuk sebagian besar kasus penggunaan.
• Antrean Postgres dapat menggantikan antrean Redis, tetapi tidak dapat menggantikan antrean SQS.
• Postgres telah digunakan untuk memproses lebih dari 400 juta event sejak sistem berjalan, dan menangani sekitar 1 juta event per hari.
• Menggunakan tabel biasa dengan SELECT FOR UPDATE SKIP LOCKED adalah pendekatan sederhana yang bekerja di semua framework ORM/Query DSL.
• Kekurangan utama menggunakan PostgreSQL sebagai bus pub/sub dengan LISTEN/NOTIFY adalah LISTEN merupakan fitur berbasis sesi, sehingga tidak kompatibel dengan connection pooling tingkat pernyataan.
• Menggunakan Postgres sebagai antrean aplikasi memiliki keuntungan transaksional, sehingga pekerjaan asinkron terjadwal mendapat manfaat darinya.
• Postgres bisa diskalakan untuk antrean, tetapi menyiapkan SQS atau stack antrean lain di AWS, GCP, Azure lebih sederhana dan memang dibuat untuk tujuan tersebut.
• Postgres menjalankan benchmark pada instance github CI di 1200 jobs/s, lalu diskalakan menjadi 5000 jobs/s dengan worker tambahan.
• Postgres dengan Oban dari Elixir telah digunakan untuk menangani ratusan ribu hingga jutaan pekerjaan per hari, dan semantik transaksional di sekitar background job terbukti praktis.
• Implementasi yang memproses 47 juta pekerjaan menekankan manfaat penyimpanan tahan lama dengan SKIP LOCKED untuk VACUUM, delayed job, retry, pembaruan status, serta indeks untuk menerapkan pola mahal seperti "setidaknya sekali".