LISTEN na NOTIFY hutoa mfumo wa messaging wa publish/subscribe uliojengwa ndani ya PostgreSQL — session moja inaweza kutuma notification kwenye channel, na sessions nyingine zinazosikiliza channel hiyo huipokea papo hapo. Ni njia nyepesi ya kusukuma matukio ya real-time kutoka kwenye database bila polling.
LISTEN order_created;
NOTIFY order_created, ;
LISTEN hujiandikisha kwa channel; NOTIFY huchapisha kwake (ikiwa na payload ya text ya hiari). Wasikilizaji hupata notification kwa njia ya asynchronous — hakuna polling inayohitajika.
-- a trigger that notifies whenever a row is inserted
CREATE FUNCTION notify_new_order() RETURNS trigger AS $$
BEGIN
PERFORM pg_notify('order_created', NEW.id::text); -- notify with the new id
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER order_notify AFTER INSERT ON orders
FOR EACH ROW EXECUTE FUNCTION notify_new_order();
-- now inserting an order automatically pushes a notification to listeners
Kuunganisha NOTIFY na trigger huruhusu database kusukuma matukio kiotomatiki wakati data inabadilika (order mpya, status update) — application servers zinazosikiliza channel huitikia kwa wakati halisi.
Application code (Node, Python, etc.) opens a connection and LISTENs on a channel.
When a NOTIFY fires (e.g. from a trigger on data change), the app receives the event
and reacts — pushing to websockets, invalidating a cache, triggering a job, etc.
→ Real-time reactions to database changes WITHOUT polling the database.
✗ Notifications are NOT persisted — if no one is listening, the message is LOST
(no durability/queue guarantees like a real message broker)
✗ Payload is small (limited size); delivered only after the transaction COMMITS
→ Good for lightweight real-time signaling; for durable/reliable messaging use a
proper broker (RabbitMQ, Kafka) or a queue table.
LISTEN/NOTIFY ni kipengele chenye manufaa, kinachojulikana kidogo zaidi cha PostgreSQL kinachotoa pub/sub messaging iliyojengwa ndani, chenye thamani kwa kuongeza real-time reactivity kwa applications bila polling.
Thamani ya msingi ni kuwezesha database kusukuma matukio kwa application sessions zinazosikiliza papo hapo wakati kitu kinapotokea (order mpya, mabadiliko ya status) — kawaida ikiunganishwa na triggers ili mabadiliko ya data yajulishe wasikilizaji kiotomatiki, ambao application servers huitikia (kusukuma kwa websockets, kufuta caches, kuchochea kazi za nyuma).
Hii ni yenye thamani kwa sababu hutoa tabia ya event-driven ya real-time bila ufanisi mdogo wa polling database mara kwa mara kuangalia mabadiliko (mfumo wa kawaida, wenye upotevu ambao LISTEN/NOTIFY huubadilisha kwa ufasaha).
Kuelewa utaratibu (LISTEN kujiandikisha, NOTIFY kuchapisha, na triggers kwa notification kiotomatiki kwa mabadiliko ya data) na jinsi applications zinavyoitumia (kusikiliza matukio kuendesha real-time reactions) ni jambo lenye manufaa kwa kujenga applications zinazoitikia, zenye msingi wa events kwa kutumia PostgreSQL pekee.
Muhimu sawa ni kujua mipaka: notifications hazihifadhiwi (zinapotea kama hakuna anayesikiliza — hakuna durability guarantees), zina payloads ndogo, na hufyatuka tu baada ya commit — hivyo zinafaa kwa signaling nyepesi ya real-time, sio mbadala wa message broker yenye durability (RabbitMQ, Kafka) wakati reliability na persistence ni muhimu.
Kwa kuwa real-time reactivity ni hitaji la kawaida na LISTEN/NOTIFY hutoa njia iliyojengwa ndani, isiyo na polling ya kuifikia kwa kesi nyepesi, kuielewa — utaratibu wa pub/sub, mfumo wa trigger, na muhimu zaidi mipaka yake (wakati inatosha dhidi ya wakati broker halisi inahitajika) — ni maarifa ya PostgreSQL yenye thamani na umuhimu wa kivitendo kwa kujenga applications zenye msingi wa events, kipengele chenye manufaa kilichojengwa ndani ambacho mara nyingi husahaulika.