21 ਅਗ 2025·8 ਮਿੰਟ
PostgreSQL LISTEN/NOTIFY: ਜਦੋਂ ਲਾਈਵ ਅੱਪਡੇਟਸ ਲਈ ਇਹ ਕਾਫੀ ਹੁੰਦਾ ਹੈ
PostgreSQL LISTEN/NOTIFY ਘੱਟ ਸੈੱਟਅਪ ਨਾਲ ਲਾਈਵ ਡੈਸ਼ਬੋਰਡ ਅਤੇ ਅਲਰਟ ਚਲਾ ਸਕਦਾ ਹੈ। ਜਾਣੋ ਇਹ ਕਿੱਥੇ ਫਿੱਟ ਹੁੰਦਾ ਹੈ, ਇਸ ਦੀਆਂ ਸੀਮਾਵਾਂ ਅਤੇ ਕਦੋਂ ਬ੍ਰੋਕਰ ਜੋੜਣਾ ਚਾਹੀਦਾ ਹੈ।
PostgreSQL LISTEN/NOTIFY ਘੱਟ ਸੈੱਟਅਪ ਨਾਲ ਲਾਈਵ ਡੈਸ਼ਬੋਰਡ ਅਤੇ ਅਲਰਟ ਚਲਾ ਸਕਦਾ ਹੈ। ਜਾਣੋ ਇਹ ਕਿੱਥੇ ਫਿੱਟ ਹੁੰਦਾ ਹੈ, ਇਸ ਦੀਆਂ ਸੀਮਾਵਾਂ ਅਤੇ ਕਦੋਂ ਬ੍ਰੋਕਰ ਜੋੜਣਾ ਚਾਹੀਦਾ ਹੈ।
ਉਤਪਾਦ ਦੀ UI 'ਚ “ਲਾਈਵ ਅੱਪਡੇਟਸ” ਆਮ ਤੌਰ 'ਤੇ ਇਸ ਦਾ ਮਤਲਬ ਹੁੰਦਾ ਹੈ ਕਿ ਕੁਝ ਹੋਣ ਦੇ ਬਾਅਦ ਸਕਰੀਨ ਤੁਰੰਤ ਬਦਲ ਜਾਂਦੀ ਹੈ, ਬਿਨਾਂ ਯੂਜ਼ਰ ਦੇ ਰੀਫ੍ਰੈਸ਼ ਕੀਤੇ। ਕਿਸੇ ਡੈਸ਼ਬੋਰਡ 'ਤੇ ਗਿਣਤੀ ਵਧ ਜਾਂਦੀ ਹੈ, ਇਨਬਾਕਸ 'ਤੇ ਲਾਲ ਬੈਜ ਆ ਜਾਂਦਾ ਹੈ, ਇੱਕ ਐਡਮਿਨ ਨੂੰ ਨਵਾਂ ਆਰਡਰ ਦਿਖਾਈ ਦੇ ਜਾਂਦਾ ਹੈ ਜਾਂ ਇੱਕ ਟੋਸਟ ਪਾਪ-ਅੱਪ ਹੁੰਦੀ ਹੈ: “Build finished” ਜਾਂ “Payment failed”。ਚੀਜ਼ ਦੀ ਕੁੰਜੀ ਸਮਾਂ ਹੁੰਦਾ ਹੈ: ਇਹ ਤੁਰੰਤ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ, ਹਾਲਾਂਕਿ ਇਹ ਇੱਕ ਜਾਂ ਦੋ ਸੈਕਿੰਡ ਹੋ ਸਕਦਾ ਹੈ।
ਕਈ ਟੀਮਾਂ ਪਹਿਲਾਂ ਪੋਲਿੰਗ ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੀਆਂ ਹਨ: ਬਰਾਊਜ਼ਰ ਸਰਵਰ ਨੂੰ ਹਰ ਕੁਝ ਸਕਿੰਡਾਂ 'ਚ ਪੁੱਛਦਾ ਹੈ “ਕੁਝ ਨਵਾਂ ਹੈ?” ਪੋਲਿੰਗ ਕੰਮ ਕਰਦੀ ਹੈ, ਪਰ ਦੋ ਆਮ ਨੁਕਸਾਨ ਹਨ।
ਪਹਿਲਾ, ਇਹ ਲੈਗੀ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਯੂਜ਼ਰਾਂ ਨੂੰ ਬਦਲਾਅ ਅਗਲੇ ਪੋਲ 'ਤੇ ਹੀ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ।
ਦੂਜਾ, ਇਹ ਮਹਿੰਗਾ ਪੈ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਬਾਰ-ਬਾਰ ਚੈਕ ਕਰ ਰਹੇ ਹੋ ਭਾਵੇਂ ਕੁਝ ਨਹੀਂ ਬਦਲੇ। ਹਜਾਰਾਂ ਯੂਜ਼ਰਾਂ ਨਾਲ ਇਹ ਸ਼ੋਰ ਬਣ ਜਾਂਦਾ ਹੈ।
PostgreSQL LISTEN/NOTIFY ਇੱਕ ਸਧਾਰਣ ਮਾਮਲੇ ਲਈ ਹੈ: “ਮੇਨੂੰ ਦੱਸੋ ਜਦੋਂ ਕੁਝ ਬਦਲਿਆ।” ਵਾਰ-ਵਾਰ ਪੁੱਛਣ ਦੀ ਬਜਾਏ, ਤੁਹਾਡੀ ਐਪ ਉਡੀਕ ਕਰ ਸਕਦੀ ਹੈ ਤੇ ਜਦੋਂ ਡੇਟਾਬੇਸ ਇੱਕ ਛੋਟੀ ਸੰਕੇਤ ਭੇਜੇ ਤਾਂ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰ ਸਕਦੀ ਹੈ।
ਇਹ ਉਹਨਾਂ UI ਲਈ ਚੰਗਾ ਫਿੱਟ ਹੈ ਜਿੱਥੇ ਇੱਕ ਹਲਕੀ ਸੁਝਾਈ ਕਾਫੀ ਹੁੰਦੀ ਹੈ। ਉਦਾਹਰਣੀ ਲਈ:
ਮੁਦਰਾ ਸਾਦਗੀ বনਾਮ ਗਾਰੰਟੀਜ਼ ਹੈ। LISTEN/NOTIFY ਜੋੜਨਾ ਆਸਾਨ ਹੈ ਕਿਉਂਕਿ ਇਹ ਪਹਿਲਾਂ ਹੀ Postgres ਵਿੱਚ ਹੈ, ਪਰ ਇਹ ਪੂਰੀ ਮੈਸੇਜਿੰਗ ਸਿਸਟਮ ਨਹੀਂ ਹੈ। ਨੋਟੀਫਿਕੇਸ਼ਨ ਇੱਕ ਸੰਕੇਤ ਹੈ, ਨਿਰੰਤਰ ਰਿਕਾਰਡ ਨਹੀਂ। ਜੇ ਕੋਈ ਲਿਸਨਰ ਡਿਸਕਨੈਕਟ ਹੋ ਜਾਏ, ਤਾਂ ਉਹ ਸੰਕੇਤ ਮਿਸ ਕਰ ਸਕਦਾ ਹੈ।
ਇਕ عملي ਤਰੀਕਾ: NOTIFY ਨੂੰ ਆਪਣੀ ਐਪ ਨੂੰ ਜਗਾਉਣ ਦਿਓ, ਫਿਰ ਆਪਣੀ ਐਪ ਟੇਬਲਾਂ ਵਿੱਚੋਂ ਸੱਚੀ ਹਾਲਤ ਪੜ੍ਹੇ।
PostgreSQL LISTEN/NOTIFY ਨੂੰ ਆਪਣੇ ਡੇਟਾਬੇਸ ਵਿੱਚ ਬਣਿਆ ਇੱਕ ਸਾਦਾ ਘੰਟੀ ਸਮਝੋ। ਤੁਹਾਡੀ ਐਪ ਘੰਟੀ ਦੇ ਵੱਜਣ ਦੀ ਉਡੀਕ ਕਰ ਸਕਦੀ ਹੈ, ਅਤੇ ਸਿਸਟਮ ਦਾ ਹੋਰ ਭਾਗ ਜਦੋਂ ਕੁਝ ਬਦਲਦਾ ਹੈ ਤਾਂ ਇਸਨੂੰ ਵੱਜਾ ਸਕਦਾ ਹੈ।
ਇੱਕ ਨੋਟੀਫਿਕੇਸ਼ਨ ਦੇ ਦੋ ਹਿੱਸੇ ਹੁੰਦੇ ਹਨ: ਇੱਕ ਚੈਨਲ ਨਾਮ ਅਤੇ ਇਕ ਵਿਕਲਪਿਕ ਪੇਲੋਡ। ਚੈਨਲ ਇੱਕ ਵਿਸ਼ਾ ਟੈਗ ਵਾਂਗ ਹੈ (ਉਦਾਹਰਣ ਲਈ orders_changed)। ਪੇਲੋਡ ਇੱਕ ਛੋਟਾ ਟੈਕਸਟ ਸੁਨੇਹਾ ਹੁੰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਜੋੜਦੇ ਹੋ (ਉਦਾਹਰਣ ਲਈ ਇੱਕ ਆਰਡਰ id). PostgreSQL ਕਿਸੇ ਢਾਂਚੇ ਨੂੰ ਲਾਜ਼ਮੀ ਨਹੀਂ ਕਰਦਾ, ਇਸ ਲਈ ਟੀਮਾਂ ਛੋਟੀ JSON ਸਟਰਿੰਗਾਂ ਭੇਜਦੀਆਂ ਹਨ।
ਨੋਟੀਫਿਕੇਸ਼ਨ ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ (ਤੁਹਾਡਾ API ਸਰਵਰ NOTIFY ਚਲਾਂਦਾ ਹੈ) ਤੋਂ ਟ੍ਰਿਗਰ ਹੋ ਸਕਦੀ ਹੈ ਜਾਂ ਡੇਟਾਬੇਸ ਦੇ ਆਪਣੀ ਟ੍ਰਿਗਰ ਰਾਹੀਂ (INSERT/UPDATE/DELETE ਤੋਂ ਬਾਅਦ ਇੱਕ ਟ੍ਰਿਗਰ NOTIFY ਚਲਾਂਦਾ ਹੈ)।
ਰਿਸੀਵਿੰਗ ਪਾਸੇ, ਤੁਹਾਡੀ ਐਪ ਸਰਵਰ ਇੱਕ ਡੇਟਾਬੇਸ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹਦੀ ਹੈ ਅਤੇ LISTEN channel_name ਚਲਾਉਂਦੀ ਹੈ। ਉਹ ਕਨੈਕਸ਼ਨ ਖੁਲਾ ਰਹਿੰਦਾ ਹੈ। ਜਦੋਂ NOTIFY channel_name, 'payload' ਹੁੰਦਾ ਹੈ, PostgreSQL ਉਸ ਚੈਨਲ ਤੇ ਸੁਣ ਰਹੀਆਂ ਸਾਰੀਆਂ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਸੁਨੇਹਾ ਭੇਜਦਾ ਹੈ। ਫਿਰ ਤੁਹਾਡੀ ਐਪ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰਦੀ ਹੈ (ਕੈਸ਼ ਰਿਫ੍ਰੈਸ਼, ਬਦਲੀ ਪੰਤੀ ਲੈਣਾ, ਬਰਾਊਜ਼ਰ ਨੂੰ WebSocket ਘਟਨਾ ਭੇਜਣਾ, ਆਦਿ)।
NOTIFY ਕੀ ਕਰਦਾ ਹੈ (ਅਤੇ ਕੀ ਨਹੀਂ)NOTIFY ਨੂੰ ਇੱਕ ਸੰਕੇਤ ਵਜੋਂ ਸਮਝੋ, ਡਿਲੀਵਰੀ ਸਰਵਿਸ ਵਜੋਂ ਨਹੀਂ:
ਇਸ ਤਰੀਕੇ ਨਾਲ ਵਰਤਿਆ ਜਾਣ 'ਤੇ, PostgreSQL LISTEN/NOTIFY ਬਿਨਾਂ ਵਾਧੂ ਇੰਫ੍ਰਾਸਟਰਕਚਰ ਦੇ ਲਾਈਵ UI ਅੱਪਡੇਟਸ ਚਲਾਉ ਸਕਦਾ ਹੈ।
LISTEN/NOTIFY ਉਨ੍ਹਾਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਚਮਕਦਾ ਹੈ ਜਿੱਥੇ ਤੁਹਾਡੀ UI ਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਨਿਊਡ ਦੀ ਲੋੜ ਹੈ ਕਿ ਕੁਝ ਬਦਲਿਆ, ਪੂਰਾ ਇਵੈਂਟ ਸਟਰੀਮ ਨਹੀਂ। ਸੋਚੋ “ਇਸ ਵਿਜਟ ਨੂੰ ਰਿਫ੍ਰੈਸ਼ ਕਰੋ” ਜਾਂ “ਨਵੀਂ ਆਈਟਮ ਹੈ” ਬਜਾਏ “ਹਰ ਕਲਿੱਕ ਨੂੰ ਕ੍ਰਮਵਾਰ ਪ੍ਰੋਸੈਸ ਕਰੋ।”
ਇਹ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਡੇਟਾਬੇਸ ਪਹਿਲਾਂ ਤੋਂ ਤੁਹਾਡੀ ਸਹੀ ਸਚਾਈ ਹੈ ਅਤੇ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ UI ਇਸ ਨਾਲ ਸਿੰਕ ਰਹੇ। ਆਮ ਪੈਟਰਨ ਇਹ ਹੈ: ਰੋਅ ਲਿਖੋ, ਇੱਕ ਛੋਟੀ ਨੋਟੀਫਿਕੇਸ਼ਨ ਭੇਜੋ ਜਿਸ ਵਿੱਚ ID ਹੋਵੇ, ਤੇ UI (ਜਾਂ API) ਤਾਜ਼ਾ ਸਥਿਤੀ ਫੇਚ ਕਰ ਲਏ।
LISTEN/NOTIFY ਆਮ ਤੌਰ ਤੇ ਕਾਫੀ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇਹਨਾਂ ਵਿੱਚੋਂ ਜ਼ਿਆਦਾਤਰ ਸੱਚ ਹਨ:
ਇੱਕ ਵੇਖਣਯੋਗ ਉਦਾਹਰਣ: ਇੱਕ ਅੰਦਰੂਨੀ ਸਹਾਇਤਾ ਡੈਸ਼ਬੋਰਡ “open tickets” ਦਿਖਾਉਂਦਾ ਹੈ ਅਤੇ “new notes” ਲਈ ਇਕ ਬੈਜ। ਜਦੋਂ ਇਕ ਏਜੈਂਟ ਨੋਟ ਜੋੜਦਾ ਹੈ, ਤੁਹਾਡਾ ਬੈਕਐਂਡ ਇਸਨੂੰ Postgres 'ਚ ਲਿਖਦਾ ਹੈ ਅਤੇ ticket_changed ਤੇ ਟਿਕਟ ID ਨਾਲ NOTIFY ਕਰਦਾ ਹੈ। ਬਰਾਊਜ਼ਰ ਇਕ WebSocket ਸੰযোগ ਰਾਹੀਂ ਇਹ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਅਤੇ ਉਸ ਇੱਕ ਟਿਕਟ ਕਾਰਡ ਨੂੰ ਫੇਚ ਕਰਦਾ ਹੈ। ਕੋਈ ਵਾਧੂ ਇੰਫ੍ਰਾਸਟਰਕਚਰ ਨਹੀਂ, ਪਰ UI ਫਿਰ ਵੀ ਜਿਉਂਦਾ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ।
LISTEN/NOTIFY ਪਹਿਲਾਂ ਵਧੀਆ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਇਸ ਦੀਆਂ ਕਠੋਰ ਸੀਮਾਵਾਂ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਨੋਟੀਫਿਕੇਸ਼ਨਾਂ ਨੂੰ ਇੱਕ ਮੈਸੇਜਿੰਗ ਸਿਸਟਮ ਵਾਂਗ ਵਰਤਨਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ ਨਾ ਕਿ ਇੱਕ ਹਲਕੀ “ਠੋੱਕ”, ਤਾਂ ਇਹ ਸੀਮਾਵਾਂ ਸਾਹਮਣੇ ਆਉਂਦੀਆਂ ਹਨ।
ਸਭ ਤੋਂ ਵੱਡੀ ਕਮੀ durability ਹੈ। ਇੱਕ NOTIFY ਕੋਈ ਕਿਊਡ ਜ਼ਾਬ ਨਹੀਂ ਹੈ। ਜੇ ਕੋਈ ਵੀ ਉਸ ਸਮੇਂ ਸੁਣ ਨਹੀਂ ਰਿਹਾ, ਸੁਨੇਹਾ ਮਿਸ ਹੋ ਜਾਂਦਾ ਹੈ। ਇੱਥੇ ਤੱਕ ਕਿ ਜਦੋਂ ਲਿਸਨਰ ਕਨੈਕਟ ਹੈ, ਇੱਕ क्रੈਸ਼, ਡੇਪਲੌਇ, ਨੈੱਟਵਰਕ ਹਿਕਅਪ ਜਾਂ ਡੇਟਾਬੇਸ ਰੀਸਟਾਰਟ ਕਨੈਕਸ਼ਨ ਡ੍ਰੌਪ ਕਰ ਸਕਦੇ ਹਨ। ਤੁਸੀਂ “ਮਿਸ ਕੀਤੇ” ਨੋਟੀਫਿਕੇਸ਼ਨਾਂ ਨੂੰ ਆਪਣੇ ਆਪ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕਰਵਾਓਗੇ।
ਡਿਸਕਨੈਕਟਸ ਯੂਜ਼ਰ-ਫੇਸਿੰਗ ਫੀਚਰਾਂ ਲਈ ਖਾਸ ਕਰਕੇ ਦੁੱਖਦਾਇਕ ਹਨ। ਸੋਚੋ ਕਿ ਇੱਕ ਡੈਸ਼ਬੋਰਡ ਨਵੀਂ ਆਰਡਰ ਦਿਖਾਂਦਾ ਹੈ। ਇੱਕ ਬਰਾਊਜ਼ਰ ਟੈਬ ਸਲੀਪ ਹੋ ਜਾਂਦੀ ਹੈ, WebSocket ਰੀਕਨੈਕਟ ਹੁੰਦਾ ਹੈ, ਅਤੇ UI “ਫਸਿਆ” ਲਗਦਾ ਹੈ ਕਿਉਂਕਿ ਇਸਨੇ ਕੁਝ ਇਵੈਂਟ ਮਿਸ ਕੀਤੇ। ਇਹਦਾ ਕੰਮ ਕਰਾਰ ਹੀ ਹੈ, ਪਰ ਇਹ ਵਰਕਅਰਾਉਂਡ ਹੋਰ ਹਿਸਿਆਂ ਦੀ ਲੋੜ ਪਾਉਂਦਾ ਹੈ: ਤੁਸੀਂ ਸਟੇਟ ਨੂੰ ਪੁਨਰ-ਨਿਰਮਾਣ ਕਰਦੇ ਹੋ ਡੇਟਾਬੇਸ ਨੂੰ ਪੁੱਛ ਕੇ ਅਤੇ NOTIFY ਨੂੰ ਸਿਰਫ਼ ਰੀਫ੍ਰੈਸ਼ ਲਈ ਸੰਕੇਤ ਰੱਖਦੇ ਹੋ।
ਫੈਨ-ਆਊਟ ਇੱਕ ਹੋਰ ਆਮ ਸਮੱਸਿਆ ਹੈ। ਇੱਕ ਇਵੈਂਟ ਸੈਂਕੜਿਆਂ ਜਾਂ ਹਜ਼ਾਰਾਂ ਲਿਸਨਰਾਂ ਨੂੰ ਜਗਾ ਸਕਦਾ ਹੈ (ਕਈ ਐਪ ਸਰਵਰ, ਕਈ ਯੂਜ਼ਰ)। ਜੇ ਤੁਸੀਂ ਇੱਕ ਸ਼ੋਰ ਵਾਲਾ ਚੈਨਲ ਵਰਗਾ orders ਵਰਤਦੇ ਹੋ, ਤਾਂ ਹਰ ਲਿਸਨਰ ਜਗਦਾ ਹੈ ਭਾਵੇਂ ਕੇਵਲ ਇੱਕ ਯੂਜ਼ਰ ਨੂੰ ਪਰਵਾਹ ਹੋਵੇ। ਇਸ ਨਾਲ CPU ਬਰਸਟ ਅਤੇ ਕਨੈਕਸ਼ਨ ਦਬਾਅ ਆ ਸਕਦਾ ਹੈ ਬੁਰੇ ਸਮੇਂ ਤੇ।
ਪੇਲੋਡ ਆਕਾਰ ਅਤੇ ਅਵਿਰਤੀ ਅਖੀਰਲੇ ਫੰਦੇ ਹਨ। NOTIFY ਪੇਲੋਡ ਛੋਟੇ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਉੱਚ-ਫ੍ਰਿਕਵੈਂਸੀ ਇਵੈਂਟ ਕਲਾਇਂਟਾਂ ਦੇ ਸੰਭਾਲਣ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਜਮ ਸਕਦੇ ਹਨ।
ਇਹ ਨਿਸ਼ਾਨੇ ਦੇਖੋ:
ਇਸ ਮੌਕੇ 'ਤੇ, NOTIFY ਨੂੰ ਇੱਕ “ਠੋਕ” ਵਜੋਂ ਰੱਖੋ ਅਤੇ ਭਰੋਸੇਯੋਗੀਤਾ ਨੂੰ ਇੱਕ ਟੇਬਲ ਜਾਂ ਇੱਕ ਪੂਰੇ ਸਨੇਹਾ ਬ੍ਰੋਕਰ ਵਿੱਚ ਸਥਾਨਾਂਤਰ ਕਰੋ।
LISTEN/NOTIFY ਨਾਲ ਇੱਕ ਭਰੋਸੇਯੋਗ ਪੈਟਰਨ ਇਹ ਹੈ ਕਿ NOTIFY ਨੂੰ ਇੱਕ ਨਿਊਡ ਸਮਝੋ, ਸੱਚਾਈ ਦਾ ਸਰੋਤ ਨਹੀਂ। ਡੇਟਾਬੇਸ ਰੋਅ ਸੱਚ ਹੈ; ਨੋਟੀਫਿਕੇਸ਼ਨ ਦੱਸਦੀ ਹੈ ਕਿ ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਕਦੋਂ ਦੇਖਣਾ ਹੈ।
ਲਿਖਤ ਇੱਕ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਦੇ ਅੰਦਰ ਕਰੋ, ਅਤੇ ਸਿਰਫ਼ ਡੇਟਾ ਬਦਲਾਅ ਕਮੇਟ ਹੋਣ ਮਗਰੋਂ ਨੋਟੀਫਾਈ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਜ਼ਲਦੀ ਨੋਟੀਫਾਈ ਕਰਦੇ ਹੋ, ਤਾਂ ਕਲਾਇੰਟ ਜਗ ਸਕਦਾ ਹੈ ਅਤੇ ਡੇਟਾ ਨਾ ਮਿਲੇ।
ਆਮ ਸੈੱਟਅਪ ਇੱਕ ਟ੍ਰਿਗਰ ਹੈ ਜੋ INSERT/UPDATE 'ਤੇ ਫਾਇਰ ਕਰਦਾ ਹੈ ਅਤੇ ਇੱਕ ਛੋਟੀ ਸੁਨੇਹਾ ਭੇਜਦਾ ਹੈ.
NOTIFY dashboard_updates, '{"type":"order_changed","order_id":123}'::text;
ਚੈਨਲ ਨਾਮ ਉਹਨਾਂ ਤਰੀਕਿਆਂ ਨਾਲ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦੇ ਹਨ ਜਿਵੇਂ ਲੋਕ ਸਿਸਟਮ ਬਾਰੇ ਸੋਚਦੇ ਹਨ। ਉਦਾਹਰਣ: dashboard_updates, user_notifications, ਜਾਂ ਪ੍ਰਤੀ-ਟੈਨੈਂਟ tenant_42_updates ਵਰਗੇ।
ਪੇਲੋਡ ਛੋਟਾ ਰੱਖੋ। ਆਈਡੈਂਟੀਫਾਇਰ ਅਤੇ ਕਿਸਮ ਦਿਓ, ਪੂਰੇ ਰਿਕਾਰਡ ਨਹੀਂ। ਇੱਕ ਵਰਤਣਯੋਗ ਡਿਫ਼ਾਲਟ ਰੂਪ ਇਹ ਹੈ:
type (ਕੀ ਹੋਇਆ)id (ਕਿਹੜਾ ਚੇਜ਼ ਬਦਲੀ)tenant_id ਜਾਂ user_idਇਸ ਨਾਲ ਬੈਂਡਵਿਡਥ ਘੱਟ ਰਹਿੰਦੀ ਹੈ ਅਤੇ ਨੋਟੀਫਿਕੇਸ਼ਨ ਲਾਗਾਂ ਵਿੱਚ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਲੀਕ ਹੋਣ ਤੋਂ ਬਚਦੇ ਹੋ।
ਕਨੈਕਸ਼ਨ ਡ੍ਰੌਪ ਹੁੰਦੇ ਹਨ। ਇਸ ਲਈ ਯੋਜਨਾ ਬਣਾਓ।
ਕਨੈਕਟ 'ਤੇ, ਜ਼ਰੂਰੀ ਚੈਨਲਾਂ ਲਈ LISTEN ਚਲਾਓ। ਡਿਸਕਨੈਕਟ 'ਤੇ, ਛੋਟੇ ਬੈਕਆਫ਼ ਨਾਲ ਮੁੜ ਕਨੈਕਟ ਕਰੋ। ਮੁੜ-ਕਨੈਕਟ 'ਤੇ, ਫਿਰ ਤੋਂ LISTEN ਚਲਾਓ (ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਆਟੋਮੈਟਿਕ ਨਹੀਂ ਰਿਹੰਦੀਆਂ)। ਮੁੜ-ਕਨੈਕਟ ਹੋਣ ਮਗਰੋਂ, ਛੋਟੀ “ਹਾਲੀਆ ਬਦਲਾਵ” ਦੀ ਫੇਚਿੰਗ ਕਰੋ ਤਾਂ ਕਿ ਅਪਡੇਟਾਂ ਜੋ ਤੁਸੀਂ ਛੱਡ ਚੁੱਕੇ ਹੋ ਸਕਦੇ ਹਨ ਢੱਕ ਜਾ ਸਕਣ।
ਜ਼ਿਆਦਾਤਰ ਲਾਈਵ UI ਅਪਡੇਟਸ ਲਈ, ਰੀਫੈਚ ਕਰਨਾ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਹੈ: ਕਲਾਇੰਟ {type, id} ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਫਿਰ ਸਰਵਰ ਤੋਂ ਤਾਜ਼ਾ ਸਥਿਤੀ ਮੰਗਦਾ ਹੈ।
ਇੰਕ੍ਰੀਮੈਂਟਲ ਪੈਚਿੰਗ ਤੇਜ਼ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਗਲਤ ਹੋਣ ਆਸਾਨ ਹੈ (ਆਰਡਰ ਤੋਂ ਬਾਹਰ ਆਉਣ ਵਾਲੇ ਇवੈਂਟ, ਆਧੇ-ਫੇਲ੍ਹ)। ਇੱਕ ਚੰਗਾ ਮੱਧਮ ਰਸਤਾ ਹੈ: ਛੋਟੇ ਸਲਾਈਸ (ਇੱਕ ਆਰਡਰ ਰੋਅ, ਇੱਕ ਟਿਕਟ ਕਾਰਡ, ਇੱਕ ਬੈਜ ਗਿਣਤੀ) ਨੂੰ ਰੀਫੈਚ ਕਰੋ ਅਤੇ ਭਾਰੀ ਐਗ੍ਰਿਗੇਟਾਂ ਨੂੰ ਛੋਟੇ ਟਾਈਮਰ 'ਤੇ ਛੱਡੋ।
ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਐਡਮਿਨ ਡੈਸ਼ਬੋਰਡ ਤੋਂ ਬਹੁਤ ਸਾਰੇ ਯੂਜ਼ਰਾਂ ਤੱਕ ਜਾਂਦੇ ਹੋ ਜਿਨ੍ਹਾਂ ਨੇ ਇੱਕੋ ਹੀ ਨੰਬਰ ਵੇਖਣੇ ਹੁੰਦੇ ਹਨ, ਚੰਗੀਆਂ ਆਦਤਾਂ ਕਲਿਆਨਿਕ SQL ਤੋਂ ਜ਼ਿਆਦਾ ਮਾਇਨੇ ਰਖਦੀਆਂ ਹਨ। LISTEN/NOTIFY ਫਿਰ ਵੀ ਚੰਗਾ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਤੁਹਾਨੂੰ ਇਹ ਡਿਜ਼ਾਈਨ ਕਰਨਾ ਪਵੇਗਾ ਕਿ ਡੇਟਾਬੇਸ ਤੋਂ ਬਰਾਊਜ਼ਰਾਂ ਤਕ ਘਟਨਾਵਾਂ ਕਿਵੇਂ ਵਗਦੀਆਂ ਹਨ।
ਆਮ ਬੇਸਲਾਈਨ ਇਹ ਹੈ: ਹਰ ਐਪ ਇੰਸਟੈਂਸ ਇੱਕ ਲੰਬੇ ਸਮੇਂ ਲਈ ਇੱਕ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹਦਾ ਹੈ ਜੋ LISTEN ਕਰਦਾ ਹੈ, ਫਿਰ ਕਨੈਕਟ ਕੀਤੇ ਕਲਾਇੰਟਾਂ ਨੂੰ ਅੱਪਡੇਟ ਧੱਕਦਾ ਹੈ। ਇਹ “ਹਰ ਇੰਸਟੈਂਸ ਲਈ ਇੱਕ ਲਿਸਨਰ” ਸੈੱਟਅਪ ਸਧਾਰਣ ਹੈ ਅਤੇ ਛੋਟੀ ਗਿਣਤੀ ਦੇ ਐਪ ਸਰਵਰਾਂ ਲਈ ਆਮ ਤੌਰ 'ਤੇ ਠੀਕ ਹੁੰਦਾ ਹੈ ਜੇ ਤੁਸੀਂ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਰੀਕਨੈਕਟ ਠਹਿਰਾ ਸਕਦੇ ਹੋ।
ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਕਈ ਐਪ ਇੰਸਟੈਂਸ (ਜਾਂ ਸਰਵਰਲੈੱਸ ਵਰਕਰ) ਹਨ, ਤਾਂ ਇੱਕ ਸਾਂਝੀ ਲਿਸਟਨਰ ਸਰਵਿਸ ਆਸਾਨ ਰਹਿੰਦੀ ਹੈ। ਇਕ ਵਾਰੀ ਸੁਣਨ ਵਾਲਾ ਇੱਕ ਛੋਟਾ ਪ੍ਰੋਸੈਸ ਇੱਕ ਵਾਰੀ LISTEN ਕਰਦਾ ਹੈ ਤੇ ਬਾਕੀ ਸਟੈਕ ਨੂੰ ਫੈਨ-ਆਊਟ ਕਰਦਾ ਹੈ। ਇਸ ਨਾਲ ਤੁਹਾਡੇ ਕੋਲ ਧੁੰਦਲੀ, ਮੈਟ੍ਰਿਕਸ ਅਤੇ ਬੈਕਪਰੈਸ਼ਰ ਜੋੜਨ ਲਈ ਇੱਕ ਜਗ੍ਹਾ ਹੋ ਜਾਂਦੀ ਹੈ।
ਬਰਾਊਜ਼ਰਾਂ ਲਈ, ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ WebSockets (ਦੋ-ਤਰਫ਼ਾ, ਇੰਟਰਐਕਟਿਵ UI ਲਈ ਵਧੀਆ) ਜਾਂ Server-Sent Events (SSE) (ਇੱਕ-ਤਰਫ਼ਾ, ਡੈਸ਼ਬੋਰਡ ਲਈ ਸਰਲ) ਨਾਲ ਧੱਕਦੇ ਹੋ। ਕਿਸੇ ਵੀ ਤਰੀਕੇ ਨਾਲ, “ਸਭ ਕੁਝ ਰੀਫ੍ਰੈਸ਼ ਕਰੋ” ਨੂੰ ਬਚੋ। "order 123 changed" ਵਰਗੇ ਸੰਕੁਚਿਤ ਸੰਕੇਤ ਭੇਜੋ ਤਾਂ ਕਿ UI ਕੇਵਲ ਆਪਣੀ ਲੋੜ ਦੀ ਚੀਜ਼ ਫੇਚ ਕਰੇ।
UI ਨੂੰ ਥ੍ਰੈਸ਼ਿੰਗ ਤੋਂ ਬਚਾਉਣ ਲਈ ਕੁਝ ਗਾਰਡਰੇਲ ਜੋੜੋ:
ਚੈਨਲ ਡਿਜ਼ਾਈਨ ਵੀ ਮੈਟਰ ਕਰਦਾ ਹੈ। ਇੱਕ ਗਲੋਬਲ ਚੈਨਲ ਦੀ ਥਾਂ, ਟੈਨੈਂਟ, ਟੀਮ ਜਾਂ ਫੀਚਰ ਅਨੁਸਾਰ ਪਾਰਟੀਸ਼ਨ ਕਰੋ ਤਾਂ ਕਿ ਕਲਾਇੰਟ ਸਿਰਫ਼ ਸਬੰਧਤ ਇਵੈਂਟ ਪ੍ਰਾਪਤ ਕਰਨ। ਉਦਾਹਰਣ: notify:tenant_42:billing ਅਤੇ notify:tenant_42:ops.
LISTEN/NOTIFY ਸਾਦਾ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ, ਜਿਸ ਕਰਕੇ ਟੀਮਾਂ ਇਸਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਦੀਆਂ ਹਨ ਤੇ ਫਿਰ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਹੈਰਾਨ ਹੋਦੀਆਂ ਹਨ। ਜ਼ਿਆਦਾਤਰ ਸਮੱਸਿਆਵਾਂ ਇਸਨੂੰ ਇੱਕ ਗਾਰੰਟੀਡ ਮੈਸੇਜ ਕਿਊ ਵਾਂਗ ਵਰਤਣ ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ।
ਜੇ ਤੁਹਾਡੀ ਐਪ ਰੀਕਨੈਕਟ ਕਰਦੀ ਹੈ (ਡੇਪਲਾਇ, ਨੈੱਟਵਰਕ ਬਲਿਪ, DB failover), ਜੋ ਵੀ NOTIFY ਉਸ ਸਮੇਂ ਭੇਜਿਆ ਗਿਆ ਸੀ ਉਹ ਗੁੰਮ ਹੋ ਜਾਂਦਾ ਹੈ। ਸੁਧਾਰ ਇਹ ਹੈ ਕਿ ਨੋਟੀਫਿਕੇਸ਼ਨ ਨੂੰ ਇੱਕ ਸੰਕੇਤ ਸਮਝੋ, ਫਿਰ ਡੇਟਾਬੇਸ ਨੂੰ ਫਿਰ ਚੈੱਕ ਕਰੋ।
ਇਕ عملي ਪੈਟਰਨ: ਅਸਲ ਇਵੈਂਟ ਨੂੰ ਇੱਕ ਟੇਬਲ ਵਿੱਚ ਰੱਖੋ (id ਅਤੇ created_at ਨਾਲ), ਫਿਰ ਰੀਕਨੈਕਟ 'ਤੇ ਆਪਣਾ ਲਾਸਟ ਸੀਨ id ਦੇ ਆਧਾਰ 'ਤੇ ਕੁਝ ਨਵੇਂ ਲਾਭੋ।
LISTEN/NOTIFY ਪੇਲੋਡ ਵੱਡੇ JSON ਬਲਾਬ ਲਈ ਨਹੀਂ ਬਣੇ। ਵੱਡੇ ਪੇਲੋਡ ਵਧੇਰੇ ਕੰਮ, ਵੱਧ ਪਾਰਸਿੰਗ, ਅਤੇ ਹੱਦਾਂ ਨੇੜੇ ਜਾਣ ਦੇ ਮੌਕੇ ਬਣਾਉਂਦੇ ਹਨ।
ਪੇਲੋਡਾਂ ਨੂੰ ਛੋਟੇ ਇੰਦਾ ਰੱਖੋ ਜਿਵੇਂ "order:123". ਫਿਰ ਐਪ ਡੇਟਾਬੇਸ ਤੋਂ ਤਾਜ਼ਾ ਸਥਿਤੀ ਪੜ੍ਹੇ।
ਇੱਕ ਆਮ ਗਲਤੀ ਹੈ ਪੇਲੋਡ ਸਾਮੱਗਰੀ ਦੇ ਆਧਾਰ 'ਤੇ UI ਡਿਜ਼ਾਈਨ ਕਰਨਾ, ਜਿਵੇਂ ਕਿ ਉਹ ਸੱਚਾਈ ਦਾ ਸਰੋਤ ਹੋਵੇ। ਇਸ ਨਾਲ ਸਕੀਮਾ ਬਦਲਣ ਅਤੇ ਕਲਾਇੰਟ ਵਰਜਨਾਂ ਨੂੰ ਡੀਫ਼ਿਕਲਟ ਹੋ ਜਾਂਦਾ ਹੈ।
ਸਾਫ਼ ਵੰਡ ਰੱਖੋ: ਦੱਸੋ ਕਿ ਕੁਝ ਬਦਲਿਆ, ਫਿਰ ਇੱਕ ਆਮ ਕਵੇਰੀ ਨਾਲ ਮੌਜੂਦਾ ਡੇਟਾ ਫੇਚ ਕਰੋ।
ਹਰ ਰੋਅ ਚੇੰਜ 'ਤੇ NOTIFY ਕਰਨ ਵਾਲੇ ਟ੍ਰਿਗਰ ਤੁਹਾਡੇ ਸਿਸਟਮ ਨੂੰ ਸਵੈ-ਢੋੰਡੀ ਕਰ ਸਕਦੇ ਹਨ, ਖਾਸ ਕਰਕੇ ਵੀਰਧੀ ਟੇਬਲਾਂ ਲਈ।
ਸਿਰਫ਼ ਮਾਇਨੇ ਰੱਖਣ ਵਾਲੇ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ 'ਤੇ ਨੋਟੀਫਾਈ ਕਰੋ (ਉਦਾਹਰਣ ਲਈ ਸਥਿਤੀ ਬਦਲਾਅ)। ਜੇ ਅਤਿ-ਛਿੜਕਟ ਅਪਡੇਟ ਹਨ, ਤਾਂ ਬੈਚ ਕਰੋ (ਇੱਕ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਦੇ ਪ੍ਰਤੀ ਇੱਕ ਨੋਟੀਫਾਈ ਜਾਂ ਇੱਕ ਸਮੇਂ ਵਿੰਡੋ 'ਤੇ) ਜਾਂ ਉਹ ਅੱਛੇ ਰਸਤੇ ਤੋਂ ਬਾਹਰ ਕਰੋ।
ਭਾਵੇਂ ਡੇਟਾਬੇਸ ਨੋਟੀਫਿਕੇਸ਼ਨ ਭੇਜ ਸਕਦਾ ਹੈ, ਤੁਹਾਡੀ UI ਫਿਰ ਵੀ ਸੰਭਾਲ ਨਾ ਕਰ ਸਕੇ। ਹਰ ਇਵੈਂਟ 'ਤੇ ਰੀ-ਰੇਂਡਰ ਕਰਨ ਵਾਲਾ ਡੈਸ਼ਬੋਰਡ ਫ੍ਰੀਜ਼ ਹੋ ਸਕਦਾ ਹੈ।
ਕਲਾਇੰਟ 'ਤੇ ਅਪਡੇਟਾਂ ਨੂੰ ਡੀਬਾਂਸ ਕਰੋ, ਬਰਸਟਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰੋ, ਅਤੇ “ਇਨਵੈਲਿਡੇਟ ਅਤੇ ਰੀਫੈਚ” ਨੂੰ “ਹਰ ਡੈਲਟ ਲਾਗੂ ਕਰੋ” ਤੋਂ ਤਰਜੀਹ ਦਿਓ। ਉਦਾਹਰਣ: ਨੋਟੀਫਿਕੇਸ਼ਨ ਬੈਲ ਤੁਰੰਤ ਅਪਡੇਟ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਡਰਾਪਡਾਊਨ ਲਿਸਟ ਨੂੰ ਵੱਧ ਤੋਂ ਵੱਧ ਕੁਝ ਸਕਿੰਟਾਂ 'ਚ ਹੀ ਰੀਫ੍ਰੈਸ਼ ਕਰੋ।
LISTEN/NOTIFY ਵਧੀਆ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਛੋਟਾ “ਕੁਝ ਬਦਲਿਆ” ਸੰਕੇਤ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਕਿ ਐਪ ਤਾਜ਼ਾ ਡੇਟਾ ਫੇਚ ਕਰ ਸਕੇ। ਇਹ ਪੂਰਾ ਮੈਸੇਜਿੰਗ ਸਿਸਟਮ ਨਹੀਂ ਹੈ।
ਉਦੋਂ ਤੱਕ ਇਸ 'ਤੇ ਆਪਣੀ UI ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ, ਇਹ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿਓ:
LISTEN/NOTIFY ਆਮ ਤੌਰ 'ਤੇ ਠੀਕ ਹੈ।ਇੱਕ عملي ਨਿਯਮ: ਜੇ ਤੁਸੀਂ NOTIFY ਨੂੰ ਇੱਕ ਨਿਊਡ (“ਜਾ ਕੇ ਰੋ-ਪੜ੍ਹੋ”) ਵਜੋਂ ਵਰਤ ਸਕਦੇ ਹੋ ਨਾ ਕਿ ਖੁਦ ਪੇਲੋਡ ਵਜੋਂ, ਤਾਂ ਤੁਸੀਂ ਸੁਰੱਖਿਅਤ ਖੇਤਰ ਵਿੱਚ ਹੋ।
ਉਦਾਹਰਣ: ਇੱਕ ਐਡਮਿਨ ਡੈਸ਼ਬੋਰਡ ਨਵੇਂ ਆਰਡਰ ਦਿਖਾਂਦਾ ਹੈ। ਜੇ ਇੱਕ ਨੋਟੀਫਿਕੇਸ਼ਨ ਮਿਸ ਹੋ ਜਾਵੇ, ਅਗਲਾ ਪੋਲ ਜਾਂ ਪੇਜ਼ ਰੀਫ੍ਰੈਸ਼ ਦੀ ਗਿਣਤੀ ਸਹੀ ਦਿਖਾਏਗਾ। ਇਹ ਚੰਗਾ ਫਿੱਟ ਹੈ। ਪਰ ਜੇ ਤੁਸੀਂ “ਇਸ ਕਾਰਡ ਨੂੰ ਚਾਰਜ ਕਰੋ” ਜਾਂ “ਇਸ ਪੈਕੇਜ ਨੂੰ ਭੇਜੋ” ਵਰਗੇ ਇਵੈਂਟ ਭੇਜ ਰਹੇ ਹੋ, ਤਾਂ ਇੱਕ ਮਿਸ ਹੋਣਾ ਅਸਲ ਘਟਨਾ ਹੋ ਸਕਦੀ ਹੈ।
ਇੱਕ ਛੋਟੀ ਸੇਲਜ਼ ਐਪ ਦੀ ਕਲਪਨਾ ਕਰੋ: ਇੱਕ ਡੈਸ਼ਬੋਰਡ ਅੱਜ ਦੀ ਆਮਦਨੀ, ਕੁੱਲ ਆਰਡਰ, ਅਤੇ "recent orders" ਸੂਚੀ ਦਿਖਾਉਂਦਾ ਹੈ। ਇਕ ਵੱਖਰੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਹਰ ਸੇਲਜ਼ਪرسਨ ਨੂੰ ਇੱਕ ਤੁਰੰਤ ਨੋਟੀਫਿਕੇਸ਼ਨ ਮਿਲਣੀ ਚਾਹੀਦੀ ਹੈ ਜਦੋਂ ਉਸ ਦੇ ਆਪਣੇ ਆਰਡਰ ਦਾ ਭੁਗਤਾਨ ਹੋ ਜਾਂਦਾ ਜਾਂ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ।
ਸਿਮਪਲ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ PostgreSQL ਨੂੰ ਸੱਚਾਈ ਦਾ ਸਰੋਤ ਸਮਝੋ, ਅਤੇ LISTEN/NOTIFY ਨੂੰ ਸਿਰਫ਼ ਉਹ ਠੋਕ ਸਮਝੋ ਜੋ ਦੱਸਦਾ ਹੈ ਕਿ ਕੁਝ ਬਦਲਿਆ।
ਜਦੋਂ ਇੱਕ ਆਰਡਰ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ ਜਾਂ ਇਸਦੀ ਸਥਿਤੀ ਬਦਲਦੀ ਹੈ, ਤੁਹਾਡਾ ਬੈਕਐਂਡ ਇੱਕ ਹੀ ਰਿਕਵੇਸਟ ਵਿੱਚ ਦੋ ਕੰਮ ਕਰਦਾ ਹੈ: ਰੋਅ ਲਿਖਦਾ/ਅਪਡੇਟ ਕਰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਇੱਕ ਛੋਟਾ NOTIFY ਭੇਜਦਾ ਹੈ (ਅਕਸਰ ਸਿਰਫ਼ ਆਰਡਰ ID ਅਤੇ ਇਵੈਂਟ ਕਿਸਮ)। UI NOTIFY ਪੇਲੋਡ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਕਰਦੀ ਲੋੜੀ ਪੂਰੀ ਡੇਟਾ ਲਈ।
ਇੱਕ عملي ਫਲੋ ਇਹ ਰਿਹਾ:
orders_events ਨੂੰ { "type": "status_changed", "order_id": 123 } ਨਾਲ NOTIFY ਕਰੋ।ਇਸ ਤਰੀਕੇ ਨਾਲ NOTIFY ਹਲਕਾ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਮਹਿੰਗੀਆਂ ਕਵੇਰੀਆਂ ਘੱਟ ਹੁੰਦੀਆਂ ਹਨ।
ਜਦੋਂ ਟ੍ਰੈਫਿਕ ਵਧਦਾ ਹੈ, ਫਟਕਾਰ ਆਉਂਦੀ ਹੈ: ਇਵੈਂਟਾਂ ਦਾ ਸਪਾਇਕ ਇੱਕ ਸਿੰਗਲ ਲਿਸਨਰ ਨੂੰ ਓਵਰਵਹਲਮ ਕਰ ਸਕਦਾ ਹੈ, ਨੋਟੀਫਿਕੇਸ਼ਨਾਂ ਰੀਕਨੈਕਟ 'ਤੇ ਛੱਡ ਜਾ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ ਤੁਹਾਨੂੰ ਗਾਰੰਟੀਡ ਡਿਲਿਵਰੀ ਅਤੇ ਰੀਪਲੇ ਦੀ ਲੋੜ ਹੋਣ ਲੱਗਦੀ ਹੈ। ਅਕਸਰ ਇਹ ਸਮਾਂ ਹੁੰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਇਕ ਜ਼ਿਆਦਾ ਭਰੋਸੇਯੋਗ ਲੇਅਰ ਜੋੜਦੇ ਹੋ (ਇੱਕ ਆਉਟਬਾਕਸ ਟੇਬਲ ਅਤੇ ਵਰਕਰ, ਫਿਰ ਜ਼ਰੂਰਤ ਪੈਣ 'ਤੇ ਬ੍ਰੋਕਰ) ਜਦੋਂ ਕਿ Postgres ਨੂੰ ਸੱਚਾਈ ਦਾ ਸਰੋਤ ਬਣਾਈ ਰੱਖਦੇ ਹੋ।
LISTEN/NOTIFY ਵਧੀਆ ਹੈ ਜਦੋਂ ਤੁਹਾਨੂੰ ਇੱਕ ਛੋਟਾ “ਕੁਝ ਬਦਲਿਆ” ਸਿਗਨਲ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਪੂਰੀ ਮੈਸੇਜਿੰਗ ਸਿਸਟਮ ਬਣਨ ਲਈ ਨਹੀਂ ਬਣਿਆ। ਜਦੋਂ ਤੁਸੀਂ ਇਵੈਂਟਸ ਨੂੰ ਸਪੋਰਟ ਸਰੋਤ ਵਜੋਂ ਨਿਰਭਰ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ, ਤਦ ਬ੍ਰੋਕਰ ਜੋੜਨ ਦਾ ਸਮਾਂ ਹੁੰਦਾ ਹੈ।
LISTEN/NOTIFY ਤੋਂ ਬਾਹਰ ਆ ਗਏ ਹੋਜੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਲੱਭਿਆ ਜਾਵੇ, ਇਕ ਬ੍ਰੋਕਰ ਤੁਹਾਨੂੰ ਦਰਦ ਤੋਂ ਬਚਾਵੇਗਾ:
LISTEN/NOTIFY ਸੁਨੇਹਿਆਂ ਨੂੰ ਬਾਅਦ ਲਈ ਸਟੋਰ ਨਹੀਂ ਕਰਦਾ। ਇਹ ਇੱਕ ਧੱਕਾ ਸੰਕੇਤ ਹੈ, ਇੱਕ ਸੰਭਾਲਿਆ ਲੌਗ ਨਹੀਂ। ਇਹ “ਇਸ ਡੈਸ਼ਬੋਰਡ ਵਿਜਟ ਨੂੰ ਰੀਫ੍ਰੈਸ਼ ਕਰੋ” ਲਈ ਉਕਤ ਹੈ, ਪਰ “ਬਿਲਿੰਗ ਸ਼ੁਰੂ ਕਰੋ” ਜਾਂ “ਇਹ ਪੈਕੇਜ ਭੇਜੋ” ਵਰਗੀਆਂ ਗੰਭੀਰ ਕਾਰਵਾਈਆਂ ਲਈ ਜੋਖਮ ਵਾਲਾ ਹੈ।
ਇਕ ਬ੍ਰੋਕਰ ਤੁਹਾਨੂੰ ਇੱਕ ਅਸਲ ਮੈਸੇਜ ਫਲੋ ਮਾਡਲ ਦਿੰਦਾ ਹੈ: ਕਿਊਜ਼ (ਕਾਮ ਕਰਨ ਲਈ), ਟਾਪਿਕਸ (ਕਈ ਨੂੰ ਬ੍ਰਾਡਕਾਸਟ), ਰੀਟੇਨਸ਼ਨ (ਮੈਸੇਜ ਨੂੰ ਮਿੰਟ ਤੋਂ ਦਿਨਾਂ ਤੱਕ ਰੱਖੋ), ਅਤੇ ਅਕਨਾਲਜਮੈਂਟ (ਕੰਸਿਊਮਰ ਪ੍ਰੋਸੈਸਿੰਗ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ)। ਇਸ ਨਾਲ ਤੁਸੀਂ “ਡੇਟਾਬੇਸ ਬਦਲਿਆ” ਨੂੰ “ਉਹ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਜੋ ਇਸ ਨਾਲ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ” ਤੋਂ ਵੱਖ ਕਰ ਸਕਦੇ ਹੋ।
ਤੁਸੀਂ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਜਟਿਲ ਟੂਲ ਚੁਣਨ ਦੀ ਲੋੜ ਨਹੀਂ। ਆਮ ਵਿਕਲਪ ਜਿਹੜੇ ਲੋਕ ਅੰਦਾਜ਼ਾ ਲਗਾਉਂਦੇ ਹਨ ਉਹ ਹਨ Redis (pub/sub ਜਾਂ streams), NATS, RabbitMQ, ਅਤੇ Kafka। ਸਹੀ ਚੋਣ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਸਿੱਧੇ ਵਰਕ ਕਿਊਜ਼ ਚਾਹੀਦੇ ਹਨ, ਕਈ ਸੇਵਾਵਾਂ ਤੱਕ ਫੈਨ-ਆਊਟ ਚਾਹੀਦਾ ਹੈ, ਜਾਂ ਇਤਿਹਾਸ ਨੂੰ ਰੀਪਲੇ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।
ਤੁਸੀਂ ਬਿਨਾਂ ਵੱਡੇ ਰੀਰਾਈਟ ਦੇ ਮਾਇਗ੍ਰੇਟ ਕਰ ਸਕਦੇ ਹੋ। ਇੱਕ عملي ਪੈਟਰਨ ਇਹ ਹੈ ਕਿ NOTIFY ਨੂੰ ਜਗਾਉਣ ਵਾਲਾ ਸਿਗਨਲ ਰੱਖੋ ਜਦੋਂ ਤੱਕ ਬ੍ਰੋਕਰ ਡਿਲਿਵਰੀ ਦਾ ਸਰੋਤ ਨਾ ਬਣ ਜਾਵੇ।
ਸਟਾਰਟ ਕਰਕੇ, ਇੱਕ “ਇਵੈਂਟ ਰੋਅ” ਨੂੰ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਵਿੱਚ ਲਿਖੋ ਤੇ ਫਿਰ ਇੱਕ ਵਰਕਰ ਉਸ ਇਵੈਂਟ ਨੂੰ ਬ੍ਰੋਕਰ 'ਤੇ ਪਬਲਿਸ਼ ਕਰੇ। ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਦੌਰਾਨ, NOTIFY ਤੁਹਾਡੇ UI ਲੇਅਰ ਨੂੰ “ਨਵੇਂ ਇਵੈਂਟਸ ਚੈਕ ਕਰੋ” ਦੱਸ ਸਕਦਾ ਹੈ, ਜਦਕਿ ਬੈਕਗ੍ਰਾਊਂਡ ਵਰਕਰ ਬ੍ਰੋਕਰ ਤੋਂ ਰਿਟ੍ਰਾਈਜ਼ ਅਤੇ ਆਡਿਟਿੰਗ ਨਾਲ ਉਪਭੋਗ ਕਰਦੇ ਹਨ।
ਇਸ ਤਰ੍ਹਾਂ, ਡੈਸ਼ਬੋਰਡ ਸਨੈਪੀ ਰਹਿੰਦੇ ਹਨ, ਅਤੇ ਗੰਭੀਰ ਵਰਕਫ਼ਲੋਜ਼ ਬੇਸਟ-ਐਫੋਰਟ ਨੋਟੀਫਿਕੇਸ਼ਨਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਨਾ ਛੱਡ ਦਿੰਦੇ ਹਨ।
ਇੱਕ ਸਕ੍ਰੀਨ ਚੁਣੋ (ਇੱਕ ਡੈਸ਼ਬੋਰਡ ਟਾਇਲ, ਇੱਕ ਬੈਜ ਗਿਣਤੀ, ਇੱਕ "ਨਵੀਂ ਨੋਟੀਫਿਕੇਸ਼ਨ" ਟੋਸਟ) ਅਤੇ ਇਸ ਨੂੰ ਐਂਡ-ਟੂ-ਐਂਡ ਵਾਇਰ ਕਰੋ। LISTEN/NOTIFY ਨਾਲ ਤੁਸੀਂ ਤੇਜ਼ ਨਤੀਜਾ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ, ਬਸ ਸਕੋਪ ਸਿਮਟਿਆ ਰੱਖੋ ਅਤੇ ਅਸਲੀ ਟ੍ਰੈਫਿਕ ਹੇਠਾਂ ਕੀ ਹੁੰਦਾ ਹੈ ਇਹ ਮਾਪੋ।
ਸਭ ਤੋਂ ਸਧਾਰਣ ਭਰੋਸੇਯੋਗ ਪੈਟਰਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: ਰੋਅ ਲਿਖੋ, ਕਮੇਟ ਕਰੋ, ਫਿਰ ਇੱਕ ਛੋਟਾ ਸਿਗਨਲ ਜਾਰੀ ਕਰੋ ਕਿ ਕੁਝ ਬਦਲਿਆ। UI ਵਿੱਚ, ਸიგਨਲ 'ਤੇ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰਕੇ ਤਾਜ਼ਾ ਸਥਿਤੀ ਫੇਚ ਕਰੋ (ਜਾਂ ਉਹ ਸਲਾਈਸ ਜਿਹੜੀ ਤੁਹਾਨੂੰ ਚਾਹੀਦੀ ਹੈ)। ਇਸ ਨਾਲ ਪੇਲੋਡ ਛੋਟੇ ਰਹਿੰਦੇ ਹਨ ਅਤੇ ਆਉਟ-ਆਫ-ਆਰਡਰ ਸੁਨੇਹਿਆਂ ਨਾਲ ਹੋਣ ਵਾਲੀਆਂ ਸੁਖੜੀਆਂ ਗਲਤੀਆਂ ਟਾਲੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।
ਸ਼ੁਰੂ ਵਿੱਚ ਬੁਨਿਆਦੀ ਓਬਜ਼ਰਵੇਬਿਲਿਟੀ ਜੋੜੋ। ਤੁਹਾਨੂੰ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਵਿਸ਼ੇਸ਼ ਟੂਲਾਂ ਦੀ ਲੋੜ ਨਹੀਂ, ਪਰ ਜਦੋਂ ਸਿਸਟਮ ਸ਼ੋਰ ਹੋਵੇ ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਉੱਤਰ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ:
ਸੰਝੇਦਾਰੀਆਂ ਨੂੰ ਨਿਰਲਜ਼ ਅਤੇ ਰੇਪੋ ਵਿੱਚ ਲਿਖੋ। ਚੈਨਲ ਨਾਮ, ਇਵੈਂਟ ਨਾਮ ਅਤੇ ਕਿਤੇ ਵੀ ਪੇਲੋਡ ਦੀ ਸ਼ੇਪ ਨਿਰਧਾਰਤ ਕਰੋ (ਭਾਵੇਂ ਕਿ ਇਹ ਸਿਰਫ਼ ID ਹੀ ਹੋ)। ਰਿਪੋ ਵਿੱਚ ਇੱਕ ਛੋਟੀ “ਇਵੈਂਟ ਕੈਟਲੌਗ” ਡ੍ਰਿਫਟ ਰੋਕਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ ਅਤੇ ਸਟੈਕ ਸਧਾਰਨ ਰੱਖਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ Koder.ai (koder.ai) ਤੁਹਾਨੂੰ ਪਹਿਲੀ ਵਰਜਨ React UI, Go ਬੈਕਐਂਡ, ਅਤੇ PostgreSQL ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ, ਫਿਰ ਜਦੋਂ ਲੋੜ ਵੱਧੇ ਤਾਂ ਇਟਰੇਟ ਕਰੋ।
Use LISTEN/NOTIFY when you only need a quick signal that something changed, like refreshing a badge count or a dashboard tile. Treat the notification as a nudge to refetch the real data from tables, not as the data itself.
Polling checks for changes on a schedule, so users often see updates late and your server does work even when nothing changed. LISTEN/NOTIFY pushes a small signal right when the change happens, which usually feels faster and avoids lots of empty requests.
No, it’s best-effort. If the listener is disconnected during a NOTIFY, it can miss the signal because notifications aren’t stored for later replay.
Keep it small and treat it as a hint. A practical default is a tiny JSON string with a type and an id, then have your app query Postgres for the current state.
A common pattern is to send the notification only after the write is committed. If you notify too early, a client can wake up and not find the new row yet.
Application code is usually easier to understand and test because it’s explicit. Triggers are useful when many different writers touch the same table and you want consistent behavior no matter who made the change.
Plan for reconnects as normal behavior. On reconnect, re-run LISTEN for the channels you need and do a quick refetch of recent state to cover anything you might have missed while offline.
Don’t have every browser connect to Postgres. A typical setup is one long-lived listener connection per backend instance, then your backend forwards events to browsers via WebSockets or SSE and the UI refetches what it needs.
Use narrower channels so only the right consumers wake up, and batch noisy bursts. Debouncing for a few hundred milliseconds and coalescing duplicate updates keeps your UI and backend from thrashing.
Graduate when you need durability, retries, consumer groups, ordering guarantees, or auditing/replay. If missing an event would cause a real incident (billing, shipping, irreversible workflows), use an outbox table plus a worker or a dedicated broker instead of relying on NOTIFY alone.