PGMQ: Antrean Pesan di PostgreSQL

Jika PostgreSQL sudah menjadi basis data aplikasi, PGMQ layak dipertimbangkan untuk antrean pekerjaan pertama. Ekstensi ini menyediakan batas waktu pesan tersembunyi, penambahan pesan dalam transaksi, dan dasar penanganan pesan gagal tanpa memasang broker terpisah.

Backend sering perlu menjalankan pekerjaan belakangan, seperti mengirim tagihan melalui surel, menghitung ulang laporan, atau mengirim webhook. Sebelum menambah Kafka atau RabbitMQ, periksa apakah antrean di basis data yang sudah ada memenuhi kebutuhan tersebut.

Antrean yang hidup di dalam basis data

PGMQ adalah extension Postgres yang menerapkan antrean pesan sebagai tabel plus API SQL: pgmq.send(), pgmq.read(), pgmq.delete(), pgmq.archive(). Tidak ada proses broker, tidak ada port baru, tidak ada artefak penerapan baru.

Pustaka klien tersedia untuk memudahkan pemakaian API — di Node, pgmq-js membungkus pembuatan antrean, send, dan pembacaan dalam beberapa panggilan. Namun ujungnya semua adalah SQL ke basis data yang sudah berjalan.

Antrean ini memakai sarana operasional PostgreSQL yang sudah tersedia: pencadangan, replikasi, pemantauan, hak akses, dan pemulihan ke titik waktu tertentu. Tim tetap perlu memeriksa cakupannya, tetapi tidak harus membangun seluruh prosedur untuk sistem kedua.

Batas waktu pesan tersembunyi

Visibility timeout adalah rentang ketika pesan yang diambil satu pekerja tidak terlihat oleh pekerja lain. Jika pekerja gagal menyelesaikan tugas, pesan dapat muncul kembali setelah rentang itu berakhir.

Model pengiriman PGMQ adalah model yang dipopulerkan SQS. Pekerja membaca pesan dengan visibility timeout — misalnya 30 detik. Pesannya tidak keluar dari antrean; selama rentang timeout itu dia hanya tak terlihat oleh pekerja lain. Selesaikan pekerjaannya lalu delete atau archive pesannya: delete menghapus pesan, sedangkan archive memindahkannya ke tabel arsip. Crash di tengah pekerjaan tanpa sempat apa-apa, dan pesannya muncul kembali begitu timeout habis, siap untuk pekerja berikutnya.

Model ini memberi pengiriman minimal satu kali (at-least-once) dan pemulihan setelah pekerja berhenti. Karena pesan dapat diproses kembali, penanganannya harus idempoten: pengulangan tidak menambah dampak bisnis kedua.

Menambahkan pesan dalam transaksi bisnis

PGMQ dapat menambahkan pesan dalam transaksi yang sama dengan data bisnis karena keduanya berada di PostgreSQL. Broker eksternal berada di sistem lain, sehingga penulisan ke basis data dan broker memerlukan rancangan koordinasi.

Dengan broker eksternal ada dua sistem, jadi ada dua mode kegagalan. Commit order tetapi gagal kirim kejadian-nya, dan sistem hilir tidak pernah dengar. Publish kejadian tetapi order-nya di-rollback, dan hilir memproses sesuatu yang tidak pernah ada.

Pola outbox menangani masalah ini dengan menulis kejadian ke tabel bersama transaksi bisnis, lalu meneruskannya ke broker. Pada PGMQ, antrean itu sendiri sudah berupa tabel pada basis data yang sama:

BEGIN;
INSERT INTO orders (...) VALUES (...);
SELECT pgmq.send('notifications', '{"order_id": 118}');
COMMIT;

Satu commit. Order dan pesannya sama-sama ada, atau sama-sama tidak. Di sebuah backend operasional yang saya bangun untuk perusahaan logistik, properti tunggal ini menghapus satu job rekonsiliasi yang satu-satunya tugasnya menangkap selisih akibat penulisan ke dua sistem antara basis data dan broker.

Beban operasional yang terlewati

Kafka berarti broker, controller quorum, partisi, kelompok pekerja, tuning retention, dan dasbor yang dipelototi saat rebalancing kacau. RabbitMQ lebih ringan, tetapi tetap satu cluster stateful lagi dengan jalur upgrade dan mode kegagalannya sendiri. Keduanya sepadan kalau memang benar-benar dibutuhkan. Namun keduanya tidak pernah gratis.

Antrean di Postgres hanya satu schema tambahan. Ia dicadangkan oleh pencadangan yang sudah berjalan, terpantau oleh pemantauan yang sudah jalan, dan memerlukan pembaruan ekstensi secara eksplisit. Untuk tim kecil, selisih itu menentukan apakah rotasi on-call masih manusiawi.

Batas kapasitas dan saat beralih ke sistem lain

Angka jujurnya: di perangkat keras sederhana saya pernah menguji kinerja PGMQ pada latensi baca satu digit milidetik dan ribuan pesan per detik — beberapa orde di atas beban backend line-of-business pada umumnya. Namun plafonnya nyata. Pekerja melakukan polling, bukan menerima push, tabel antrean yang sibuk membutuhkan perhatian vacuum, dan semuanya berbagi I/O dengan aplikasinya.

Pertimbangkan sistem lain ketika kebutuhan berubah: puluhan ribu pesan per detik secara terus-menerus, pemutaran ulang riwayat, atau kelompok pembaca independen yang memerlukan aliran sama. Kafka dirancang sebagai log kejadian, sedangkan PGMQ lebih dekat ke antrean tugas. Pilih sesuai perilaku yang dibutuhkan.

Pesan gagal yang perlu dipisahkan

Pesan yang selalu membuat pekerja gagal perlu dipisahkan agar tidak dicoba tanpa batas. PGMQ mencatat jumlah pembacaan pada read_ct. Ketika jumlah itu melewati ambang, pindahkan pesan ke antrean gagal dan hapus atau arsipkan pesan asli dalam transaksi basis data yang sama; pantau jumlah pesan gagal. Pesan yang diarsipkan juga tetap dapat diperiksa sebagai jejak pemrosesan.

Intinya

PGMQ memberi pilihan antrean tugas dengan operasi yang mengikuti PostgreSQL. Pertimbangkan batas waktu pesan, sifat idempoten pekerja, transaksi bisnis, dan beban I/O bersama. Gunakan Kafka atau broker lain jika kebutuhan log kejadian serta pembaca independen memang menuntutnya.

Ini filosofi yang sama dengan pengelompokan lintas zona waktu di PostgreSQL: dorong pekerjaannya ke basis data yang memang sudah ada. Banyak backend IoT yang saya bangun menjalankan job antreannya persis seperti ini.