ਇੱਕ ਵੈਲੇਟ ਐਡਰੈੱਸ ਕੋਈ ਭੁਗਤਾਨ ਪ੍ਰਣਾਲੀ ਨਹੀਂ ਹੈ। ਇਹ ਸਿਰਫ਼ ਇੱਕ ਮੰਜ਼ਿਲ ਹੈ, ਹੋਰ ਕੁਝ ਨਹੀਂ। ਜਿਸ ਕਿਸੇ ਕੋਲ ਵੀ ਇਹ ਸਟ੍ਰਿੰਗ ਹੈ, ਉਹ ਕਿਸੇ ਵੀ ਸਮੇਂ ਇਸ 'ਤੇ ਕੁਝ ਵੀ ਭੇਜ ਸਕਦਾ ਹੈ। ਦੋ ਲੋਕਾਂ ਵਿਚਕਾਰ ਇੱਕ ਵਾਰ ਦੇ ਲੈਣ-ਦੇਣ ਲਈ, ਜੋ ਇੱਕ ਦੂਜੇ 'ਤੇ ਭਰੋਸਾ ਕਰਦੇ ਹਨ, ਇਹ ਕਾਫ਼ੀ ਹੋ ਸਕਦਾ ਹੈ। ਪਰ ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ SaaS ਉਤਪਾਦ, ਇੱਕ ਮਾਰਕੀਟਪਲੇਸ, ਜਾਂ ਇੱਕ ਆਨਲਾਈਨ ਸਟੋਰ ਚਲਾਉਂਦੇ ਹੋ, ਤਾਂ ਚੈੱਕਆਊਟ ਪੇਜ 'ਤੇ ਇੱਕ ਸਥਿਰ (static) ਐਡਰੈੱਸ ਪੇਸਟ ਕਰਨਾ ਕਾਰਜਸ਼ੀਲ ਅਰਾਜਕਤਾ (operational chaos) ਦਾ ਕਾਰਨ ਬਣ ਸਕਦਾ ਹੈ। ਤੁਸੀਂ ਆਪਣੇ ਦਿਨ ਰਹੱਸਮਈ ਲੈਣ-ਦੇਣ ਨੂੰ ਅਸਲ ਗਾਹਕਾਂ ਨਾਲ ਮਿਲਾਉਣ, ਇਹ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਵਿੱਚ ਬਿਤਾਓਗੇ ਕਿ ਕਿਸਨੇ ਕੀ ਅਦਾ ਕੀਤਾ ਹੈ, ਅਤੇ ਜਦੋਂ ਕੋਈ ਗਲਤ ਨੈੱਟਵਰਕ 'ਤੇ ਗਲਤ ਟੋਕਨ ਭੇਜ ਦਿੰਦਾ ਹੈ ਤਾਂ ਉਸ ਗੜਬੜ ਨੂੰ ਸੁਧਾਰਨ ਵਿੱਚ ਲੱਗੇ ਹੋਵੋਗੇ।

ਕੁਝ ਅਜਿਹਾ ਬਣਾਉਣ ਲਈ ਜੋ ਵਧੇਰੇ ਪੱਧਰ (scale) 'ਤੇ ਕੰਮ ਕਰ ਸਕੇ, ਤੁਹਾਨੂੰ ਇੱਕ ਦਾਨ ਪਾਤਰ ਵਾਂਗ ਸੋਚਣਾ ਬੰਦ ਕਰਨਾ ਹੋਵੇਗਾ ਅਤੇ ਇੱਕ ਸੰਰਚਿਤ ਭੁਗਤਾਨ ਪ੍ਰਣਾਲੀ ਵਾਂਗ ਸੋਚਣਾ ਸ਼ੁਰੂ ਕਰਨਾ ਹੋਵੇਗਾ।

ਵਧੇਰੇ ਪੱਧਰ 'ਤੇ ਵੈਲੇਟ ਐਡਰੈੱਸ ਕਿਉਂ ਅਸਫਲ ਰਹਿੰਦਾ ਹੈ

ਸਮੱਸਿਆ ਸੰਦਰਭ (context), ਜਾਂ ਉਸਦੀ ਘਾਟ ਹੈ। ਜਦੋਂ ਕੋਈ ਗਾਹਕ ਤੁਹਾਡਾ ਵੈਲੇਟ ਐਡਰੈੱਸ ਕਾਪੀ ਕਰਦਾ ਹੈ ਅਤੇ ਕਿਸੇ ਐਕਸਚੇਂਜ ਜਾਂ ਸੈਲਫ-ਕਸਟਡੀ ਵੈਲੇਟ ਤੋਂ ਕ੍ਰਿਪਟੋ ਭੇਜਦਾ ਹੈ, ਤਾਂ ਬਲਾਕਚੈਨ ਸਿਰਫ਼ ਉਹੀ ਰਿਕਾਰਡ ਕਰਦਾ ਹੈ ਜੋ ਹੁੰਦਾ ਹੈ: ਇੱਕ ਰਕਮ, ਇੱਕ ਸਮਾਂ (timestamp), ਅਤੇ ਦੋ ਪਬਲਿਕ ਐਡਰੈੱਸ। ਇਹ ਤੁਹਾਡਾ ਇਨਵੌਇਸ ਨੰਬਰ ਰਿਕਾਰਡ ਨਹੀਂ ਕਰਦਾ। ਇਸ ਵਿੱਚ ਗਾਹਕ ਦੀ ID ਸ਼ਾਮਲ ਨਹੀਂ ਹੁੰਦੀ। ਇਹ ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਟ੍ਰਾਂਸਫਰ ਇੱਕ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਰੀਨਿਊਅਲ ਹੈ, ਇੱਕ ਪ੍ਰੋ-ਰੇਟਿਡ ਅੱਪਗ੍ਰੇਡ ਹੈ, ਜਾਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਵੀਂ ਖਰੀਦਦਾਰੀ ਹੈ।

ਇੱਕ SaaS ਕੰਪਨੀ ਬਾਰੇ ਵਿਚਾਰ ਕਰੋ ਜੋ ਹਰ ਮਹੀਨੇ ਪੰਜ ਸੌ ਗਾਹਕਾਂ ਨੂੰ ਸਟੇਬਲਕੋਇਨਜ਼ ਵਿੱਚ ਬਿਲਿੰਗ ਕਰਦੀ ਹੈ। ਜੇਕਰ ਹਰ ਗਾਹਕ ਇੱਕੋ ਸਥਿਰ ਐਡਰੈੱਸ 'ਤੇ USDT ਭੇਜਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੀ ਅਕਾਊਂਟਿੰਗ ਟੀਮ ਲਈ ਇੱਕ ਸਪ੍ਰੈਡਸ਼ੀਟ ਦਾ ਕੋਹਲਮ ਹੋ ਜਾਵੇਗਾ। ਇੱਕ ਟ੍ਰਾਂਸਫਰ ਦੂਜੇ ਵਰਗਾ ਹੀ ਲੱਗਦਾ ਹੈ। ਤੁਸੀਂ ਇਹ ਨਹੀਂ ਦੱਸ ਸਕਦੇ ਕਿ ਰਾਤ 2 ਵਜੇ ਆਏ ਵੀਹ ਡਾਲਰ ਗਾਹਕ A ਦੇ ਆਪਣੇ ਪਲਾਨ ਨੂੰ ਰੀਨਿਊ ਕਰਨ ਸਨ ਜਾਂ ਗਾਹਕ B ਦੇ ਮਿਡ-ਸਾਈਕਲ ਅੱਪਗ੍ਰੇਡ ਸਨ। ਬਲਾਕਚੈਨ ਸਿਰਫ਼ ਇੱਕ ਅੰਕ ਦੇਖਦਾ ਹੈ। ਤੁਹਾਡੇ ਕਾਰੋਬਾਰ ਨੂੰ ਇੱਕ ਕਹਾਣੀ ਦੀ ਲੋੜ ਹੈ।

ਮਾਰਕੀਟਪਲੇਸ ਲੈਣ-ਦੇਣ ਦੇ ਦੋਵਾਂ ਪਾਸਿਆਂ 'ਤੇ ਇਸ ਦਰਦ ਨੂੰ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ। ਤੁਹਾਨੂੰ ਇਹ ਜਾਣਨ ਦੀ ਲੋੜ ਹੈ ਕਿ ਖਰੀਦਦਾਰ ਨੇ ਫੰਡ ਜਮ੍ਹਾਂ ਕਰ ਦਿੱਤੇ ਹਨ, ਵਿਕਰੇਤਾ ਦੁਆਰਾ ਸਾਮਾਨ ਭੇਜਣ ਤੱਕ ਉਹਨਾਂ ਨੂੰ ਰੋਕ ਕੇ ਰੱਖੋ, ਅਤੇ ਡਿਲੀਵਰੀ ਦੀ ਪੁਸ਼ਟੀ ਤੋਂ ਬਾਅਦ ਹੀ ਉਹਨਾਂ ਨੂੰ ਰਿਲੀਜ਼ ਕਰੋ। ਇੱਕ ਕੱਚਾ (raw) ਐਡਰੈੱਸ ਤੁਹਾਨੂੰ ਖਰੀਦਦਾਰ ਦੇ ਡਿਪਾਜ਼ਿਟ ਨੂੰ ਕਿਸੇ ਰੈਂਡਮ ਇਨਬਾਊਂਡ ਟ੍ਰਾਂਸਫਰ ਜਾਂ ਵਿਕਰੇਤਾ ਦੇ ਆਪਣੇ ਫੰਡਾਂ ਤੋਂ ਵੱਖ ਕਰਨ ਦਾ ਕੋਈ ਪ੍ਰੋਗਰਾਮੈਟਿਕ ਤਰੀਕਾ ਨਹੀਂ ਦਿੰਦਾ। ਈ-ਕਾਮਰਸ ਵੀ ਉਨਾ ਹੀ ਉਲਝਣ ਭਰਿਆ ਹੈ। ਕਿਸੇ ਖਾਸ ਆਰਡਰ ਨਾਲ ਟ੍ਰਾਂਸਫਰ ਨੂੰ ਜੋੜੇ ਬਿਨਾਂ, ਤੁਸੀਂ ਫੁਲਫਿਲਮੈਂਟ (fulfillment) ਸ਼ੁਰੂ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਕਿਸੇ ਨੂੰ ਮੈਨੁਅਲੀ ਚੇਨ ਨੂੰ ਸਕੈਨ ਕਰਨਾ ਪਵੇਗਾ, ਟ੍ਰਾਂਸਫਰ ਲੱਭਣਾ ਪਵੇਗਾ, ਅਤੇ ਤੁਹਾਡੇ ਡਾਟਾਬੇਸ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨਾ ਪਵੇਗਾ। ਅਜਿਹਾ ਦਿਨ ਵਿੱਚ ਦਸ ਵਾਰ ਕਰੋਗੇ ਤਾਂ ਤੁਸੀਂ ਮੈਚ ਕਰਨਾ ਭੁੱਲ ਜਾਵੋਗੇ। ਇਸ ਨੂੰ ਹਜ਼ਾਰ ਵਾਰ ਕਰੋਗੇ ਤਾਂ ਤੁਸੀਂ ਪੈਸੇ ਗੁਆ ਬੈਠੋਗੇ।

ਇਹ ਬਦਲਾਅ ਸਰਲ ਹੈ ਪਰ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਇਹ ਪੁੱਛਣਾ ਬੰਦ ਕਰੋ ਕਿ ਕੀ ਫੰਡ ਕਿਸੇ ਐਡਰੈੱਸ 'ਤੇ ਪਹੁੰਚ ਗਏ ਹਨ। ਇਹ ਪੁੱਛਣਾ ਸ਼ੁਰੂ ਕਰੋ ਕਿ ਕੀ ਇੱਕ ਖਾਸ ਭੁਗਤਾਨ ਬੇਨਤੀ (payment request) ਸਹੀ ਸਥਿਤੀ (state) ਤੱਕ ਪਹੁੰਚ ਗਈ ਹੈ।

ਭੁਗਤਾਨ ਬੇਨਤੀ (Payment Request) ਦੇ ਆਲੇ-ਦੁਆਲੇ ਬਣਾਓ

ਇੱਕ ਭਰੋਸੇਯੋਗ ਕ੍ਰਿਪਟੋ ਭੁਗਤਾਨ ਪ੍ਰਵਾਹ (flow) ਭੁਗਤਾਨ ਬੇਨਤੀ ਨੂੰ ਕੇਂਦਰੀ ਵਸਤੂ (central object) ਵਜੋਂ ਮੰਨਦਾ ਹੈ। ਵੈਲੇਟ ਐਡਰੈੱਸ ਇੱਕ ਅਸਥਾਈ ਕੰਟੇਨਰ ਬਣ ਜਾਂਦਾ ਹੈ ਜੋ ਬੇਨਤੀ ਦੀ ਸੇਵਾ ਵਿੱਚ ਮੌਜੂਦ ਹੁੰਦਾ ਹੈ। ਬੇਨਤੀ ਉਹ ਮੈਟਾਡਾਟਾ (metadata) ਲੈ ਕੇ ਚਲਦੀ ਹੈ ਜੋ ਇੱਕ ਬਲਾਕਚੈਨ ਟ੍ਰਾਂਸਫਰ ਨੂੰ ਇੱਕ ਪਛਾਣਨਯੋਗ ਕਾਰੋਬਾਰੀ ਘਟਨਾ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ।

ਚੈੱਕਆਊਟ ਵਿਕਲਪ ਪੇਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਉਹ ਡਾਟਾ ਪੁਆਇੰਟ ਨਿਰਧਾਰਤ ਕਰੋ ਜੋ ਭੁਗਤਾਨ ਨੂੰ ਪਛਾਣਨਯੋਗ ਬਣਾਉਂਦੇ ਹਨ:

  • ਇੱਕ ਖਰੀਦਦਾਰੀ ਜਾਂ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ID, ਤਾਂ ਜੋ ਤੁਹਾਨੂੰ ਪਤਾ ਹੋਵੇ ਕਿ ਪੈਸੇ ਕਿਉਂ ਜਾ ਰਹੇ ਹਨ।
  • ਉਮੀਦ ਕੀਤੀ ਗਈ ਰਕਮ, ਜੋ ਦਸ਼ਮਲਵ (decimal) ਤੱਕ ਸਪਸ਼ਟ ਹੋਵੇ।
  • ਸਹੀ ਐਸੇਟ (asset) ਅਤੇ ਨੈੱਟਵਰਕ ਕਿਸਮ, ਕਿਉਂਕਿ Ethereum 'ਤੇ USDT ਭੇਜਣਾ Tron ਜਾਂ Polygon 'ਤੇ ਭੇਜਣ ਦੇ ਬਰਾਬਰ ਨਹੀਂ ਹੈ।
  • ਗਾਹਕ ਜਾਂ ਅੰਦਰੂਨੀ ਖਾਤੇ ਦਾ ਹਵਾਲਾ।
  • ਇੱਕ ਮਿਆਦ (expiration time), ਤਾਂ ਜੋ ਮਾਰਚ ਦਾ ਅਧੂਰਾ ਭੁਗਤਾਨ ਵਾਲਾ ਕੋਟੇਸ਼ਨ ਜੂਨ ਵਿੱਚ ਅਚਾਨਕ ਕਿਸੇ ਆਰਡਰ ਨੂੰ ਬੰਦ ਨਾ ਕਰ ਦੇਵੇ।

ਜਦੋਂ ਕੋਈ ਗਾਹਕ 'pay' 'ਤੇ ਕਲਿੱਕ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡਾ ਸਿਸਟਮ ਇਹਨਾਂ ਫੀਲਡਾਂ ਵਾਲੀ ਇੱਕ ਬੇਨਤੀ ਤਿਆਰ ਕਰਦਾ ਹੈ। ਗਾਹਕ ਫਿਰ ਸਿਰਫ਼ ਇੱਕ ਐਡਰੈੱਸ ਦੇ ਬਜਾਏ ਉਸ ਖਾਸ ਬੇਨਤੀ ਦੇ ਵਿਰੁੱਧ ਭੁਗਤਾਨ ਕਰਦਾ ਹੈ। ਚੇਨ 'ਤੇ ਟ੍ਰਾਂਸਫਰ ਹੁਣ ਇੱਕ ਆਫ-ਚੇਨ ਪਛਾਣ ਰੱਖਦਾ ਹੈ। ਤੁਹਾਡਾ ਸਿਸਟਮ ਬਲਾਕ ਐਕਸਪਲੋਰਰ ਨੂੰ ਕੁਐਰੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਜਾਣਦਾ ਹੈ ਕਿ ਭੁਗਤਾਨ ਕਿਸ ਲਈ ਹੈ।

ਸਥਿਤੀ (Status) ਨੂੰ ਇਮਾਨਦਾਰੀ ਨਾਲ ਮਾਡਲ ਕਰੋ

ਬਲਾਕਚੈਨ 'ਤੇ ਪੈਸਾ ਪੜਾਵਾਂ ਵਿੱਚ ਹੁੰਦਾ ਹੈ। ਤੁਹਾਡੇ ਅੰਦਰੂਨੀ ਸਿਸਟਮ ਨੂੰ ਅਜਿਹੀ ਸ਼ਬਦਾਵਲੀ ਦੀ ਲੋੜ ਹੈ ਜੋ ਉਹਨਾਂ ਪੜਾਵਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੋਵੇ, ਨਹੀਂ ਤਾਂ ਤੁਹਾਡੀਆਂ ਇੰਜੀਨੀਅਰਿੰਗ, ਸਪੋਰਟ, ਅਤੇ ਆਪਰੇਸ਼ਨਲ ਟੀਮਾਂ ਇੱਕ ਦੂਜੇ ਤੋਂ ਬਿਨਾਂ ਗੱਲ ਕਰਨਗੀਆਂ।

ਮਾਡਲ ਨੂੰ ਸਰਲ ਅਤੇ ਵਰਣਨਸ਼ੀਲ ਰੱਖੋ। ਇੱਕ ਗੈਰ-ਤਕਨੀਕੀ ਸਪੋਰਟ ਏਜੰਟ ਸਟੇਟਸ (ਸਥਿਤੀ) ਨੂੰ ਪੜ੍ਹ ਕੇ ਇਹ ਜਾਣਨ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਗਾਹਕ ਨੂੰ ਕੀ ਦੱਸਣਾ ਹੈ।

  • Created: ਰਿਕਵੈਸਟ ਮੌਜੂਦ ਹੈ, ਪਰ ਬਲਾਕਚੇਨ 'ਤੇ ਅਜੇ ਕੁਝ ਵੀ ਦਿਖਾਈ ਨਹੀਂ ਦੇ ਰਿਹਾ। ਗਾਹਕ ਨੇ ਅਜੇ ਤੱਕ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਬ੍ਰੌਡਕਾਸਟ ਨਹੀਂ ਕੀਤੀ ਹੈ।
  • Detected: ਤੁਹਾਡੀ ਮਾਨੀਟਰਿੰਗ ਨੇ ਮੇਮਪੂਲ (mempool) ਜਾਂ ਕਿਸੇ ਹਾਲੀਆ ਬਲਾਕ ਵਿੱਚ ਇੱਕ ਸਬੰਧਤ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਦੇਖੀ ਹੈ, ਪਰ ਇਸ ਵਿੱਚ ਅਜੇ ਫਾਈਨੈਲਿਟੀ (finality) ਦੀ ਕਮੀ ਹੈ। ਉਤਪਾਦ ਨੂੰ ਸ਼ਿਪ ਨਾ ਕਰੋ।
  • Confirming: ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਚੇਨ 'ਤੇ ਹੈ ਅਤੇ ਕਨਫਰਮੇਸ਼ਨਾਂ ਇਕੱਠੀਆਂ ਕਰ ਰਹੀ ਹੈ। ਚੇਨਾਂ ਵੱਖ-ਵੱਖ ਗਤੀ ਨਾਲ ਚੱਲਦੀਆਂ ਹਨ। ਬਿਟਕੋਇਨ (Bitcoin) ਨੂੰ ਛੇ ਬਲਾਕਾਂ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। ਤੁਹਾਡੇ ਜੋਖਮ ਲੈਣ ਦੀ ਸਮਰੱਥਾ (risk appetite) ਦੇ ਅਧਾਰ 'ਤੇ ਇਥੇਰੀਅਮ (Ethereum) ਨੂੰ ਬਾਰਾਂ ਜਾਂ ਇਸ ਤੋਂ ਵੱਧ ਬਲਾਕਾਂ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। ਤੁਹਾਡੇ ਸਿਸਟਮ ਨੂੰ ਨੈੱਟਵਰਕ ਦੇ ਆਪਣੇ ਵਿਵਹਾਰ ਦਾ ਸਤਿਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
  • Completed: ਭੁਗਤਾਨ ਅਨੁਮਾਨਿਤ ਰਕਮ, ਐਸੇਟ, ਨੈੱਟਵਰਕ ਅਤੇ ਸੰਦਰਭ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ। ਤੁਹਾਡੇ ਦੁਆਰਾ ਨਿਰਧਾਰਤ ਕੀਤੀਆਂ ਗਈਆਂ ਸਾਰੀਆਂ ਸ਼ਰਤਾਂ ਪੂਰੀਆਂ ਹੋ ਗਈਆਂ ਹਨ। ਹੁਣ ਤੁਸੀਂ ਆਰਡਰ ਪੂਰਾ ਕਰ ਸਕਦੇ ਹੋ, ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਨੂੰ ਐਕਟੀਵੇਟ ਕਰ ਸਕਦੇ ਹੋ, ਜਾਂ ਐਸਕਰੋ (escrow) ਨੂੰ ਰਿਲੀਜ਼ ਕਰ ਸਕਦੇ ਹੋ।
  • Expired: ਗਾਹਕ ਭੁਗਤਾਨ ਦੀ ਸਮਾਂ ਸੀਮਾ ਗੁਆ ਬੈਠਾ ਹੈ। ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਇਸਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਮੁੜ-ਐਕਟੀਵੇਟ ਨਹੀਂ ਕਰਦੇ, ਉਦੋਂ ਤੱਕ ਰਿਕਵੈਸਟ ਨੂੰ ਭਵਿੱਖ ਦੇ ਭੁਗਤਾਨ ਸਵੀਕਾਰ ਨਹੀਂ ਕਰਨੇ ਚਾਹੀਦੇ।
  • Mismatch: ਗਾਹਕ ਨੇ ਫੰਡ ਭੇਜੇ ਹਨ, ਪਰ ਕੁਝ ਗਲਤ ਹੈ। ਰਕਮ ਘੱਟ ਹੈ, ਨੈੱਟਵਰਕ ਵੱਖਰਾ ਹੈ, ਜਾਂ ਐਸੇਟ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ। ਇਸ ਨੂੰ ਸਪੋਰਟ (support) ਨੂੰ ਭੇਜੋ। ਆਪਣੇ ਫੁਲਫਿਲਮੈਂਟ ਸਿਸਟਮ ਨੂੰ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਨਾ ਦਿਓ।

ਇਹ ਪਾਈਪਲਾਈਨ ਚੇਨ ਡੇਟਾ ਦੇ ਇੱਕ ਅਵਿਵਸਥਿਤ ਪ੍ਰਵਾਹ ਨੂੰ ਇੱਕ ਅਜਿਹੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ ਜਿਸ ਬਾਰੇ ਤੁਹਾਡੀ ਪੂਰੀ ਕੰਪਨੀ ਵਿਚਾਰ ਕਰ ਸਕਦੀ ਹੈ।

ਪੋਲਿੰਗ (Polling) ਬੰਦ ਕਰੋ। ਸੁਣਨਾ (Listening) ਸ਼ੁਰੂ ਕਰੋ।

ਇਨਫਰਾਸਟ੍ਰਕਚਰ ਬਜਟ ਖ਼ਰਚ ਕਰਨ ਦੇ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡਾ ਬੈਕਐਂਡ (backend) ਹਰ ਕੁਝ ਸਕਿੰਟਾਂ ਬਾਅਦ ਆਪਣੇ ਪ੍ਰਦਾਤਾ (provider) ਨੂੰ ਪੁੱਛਦਾ ਰਹੇ ਕਿ ਪੈਸੇ ਆਏ ਹਨ ਜਾਂ ਨਹੀਂ। ਇਹ ਦੋਵਾਂ ਪਾਸਿਆਂ 'ਤੇ ਸਰੋਤਾਂ ਦੀ ਬਰਬਾਦੀ ਕਰਦਾ ਹੈ ਅਤੇ ਬੇਲੋੜੀ ਲੇਟੈਂਸੀ (latency) ਵਧਾਉਂਦਾ ਹੈ।

ਇੱਕ ਬਿਹਤਰ ਆਰਕੀਟੈਕਚਰ ਸਟੇਟਸ-ਨੋਟੀਫਿਕੇਸ਼ਨ ਮਾਡਲ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਤੁਹਾਡੇ ਭੁਗਤਾਨ ਪ੍ਰਦਾਤਾ ਜਾਂ ਨੋਡ ਇਨਫਰਾਸਟ੍ਰਕਚਰ ਨੂੰ ਸਟੇਟਸ ਬਦਲਦੇ ਹੀ ਤੁਹਾਡੇ ਸਿਸਟਮ ਨੂੰ ਇੱਕ ਈਵੈਂਟ (event) ਭੇਜਣਾ ਚਾਹੀਦਾ ਹੈ। ਜਦੋਂ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਦਾ ਪਤਾ ਲੱਗਦਾ ਹੈ ਤਾਂ ਤੁਹਾਨੂੰ ਇੱਕ ਵੈੱਬਹੁਕ (webhook) ਮਿਲਦਾ ਹੈ, ਜਦੋਂ ਇਹ ਕਨਫਰਮ ਹੋ ਰਹੀ ਹੁੰਦੀ ਹੈ ਤਾਂ ਇੱਕ ਹੋਰ, ਅਤੇ ਜਦੋਂ ਇਹ ਪੂਰੀ ਹੋ ਜਾਂਦੀ ਹੈ ਜਾਂ ਫੇਲ ਹੋ ਜਾਂਦੀ ਹੈ ਤਾਂ ਇੱਕ ਅੰਤਿਮ ਵੈੱਬਹੁਕ ਮਿਲਦਾ ਹੈ।

ਇਹ ਬੇਲੋੜੇ CPU ਸਾਈਕਲ ਦੀ ਵਰਤੋਂ ਕੀਤੇ ਬਿਨਾਂ ਤੁਹਾਡੇ ਸਿਸਟਮ ਨੂੰ ਰਿਸਪੌਂਸਿਵ (responsive) ਰੱਖਦਾ ਹੈ।