ਸੁਰੱਖਿਅਤ ਤੀਜੇ-ਪੱਖ API ਇੰਟੀਗ੍ਰੇਸ਼ਨ: ਰੀਟ੍ਰਾਈਜ਼, ਟਾਈਮਆਊਟ, ਸਰਕਿਟ ਬ੍ਰੇਕਰ

ਕਿਉਂ ਤੀਜੇ-ਪੱਖ API ਤੁਹਾਡੇ ਮੁੱਖ ਵਰਕਫਲੋਜ਼ ਨੂੰ ਫਸਾ ਸਕਦੇ ਹਨ

ਇੱਕ ਤੀਜਾ-ਪੱਖ API ਓਸ ਤਰ੍ਹਾਂ ਫੇਲ ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਸਾਫ "ਡਾਊਨ" ਘਟਨਾ ਵਾਂਗ ਨਹੀਂ ਲੱਗਦੀ। ਸਭ ਤੋਂ ਆਮ ਸਮੱਸਿਆ ਸੁਸਤ ਹੋਣਾ ਹੈ: ਰਿਕਵੇਸਟ ਹਨਗੀ ਹੋ ਜਾਂਦੇ ਹਨ, ਜਵਾਬ ਦੇਰੀ ਨਾਲ ਆਉਂਦੇ ਹਨ, ਅਤੇ ਤੁਹਾਡੀ ਐਪ ਉਡੀਕ ਕਰਦੀ ਰਹਿੰਦੀ ਹੈ। ਜੇ ਇਹ ਕਾਲਾਂ critical path 'ਤੇ ਹਨ, ਤਾਂ ਤੁਹਾਡੇ ਕੰਟਰੋਲ ਦੇ ਬਾਹਰ ਇੱਕ ਛੋਟਾ ਠਹਿਰਾਵ਼ ਤੁਹਾਡੇ ਸਿਸਟਮ ਵਿੱਚ ਘੱਟ ਸਮੇਂ ਵਿੱਚ ਹੀ ਇਕੱਠਾ ਹੋ ਸਕਦਾ ਹੈ।

ਇਸੇ ਤਰ੍ਹਾਂ ਇੱਕ ਲੋਕਲ ਸੁਸਤਤਾ ਪੂਰੀ outage ਬਣ ਜਾਂਦੀ ਹੈ। ਥ੍ਰੈਡ ਜਾਂ ਵਰਕਰ ਉਡੀਕ ਵਿਚ ਫੱਸ ਜਾਂਦੇ ਹਨ, ਕਤਾਰਾਂ ਵੱਧਦੀਆਂ ਹਨ, ਡੇਟਾਬੇਸ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਲੰਬੇ ਸਮੇਂ ਲਈ ਖੁੱਲ੍ਹੇ ਰਹਿੰਦੇ ਹਨ, ਅਤੇ ਨਵੀਆਂ ਰਿਕਵੇਸਟਾਂ ਟਾਈਮਆਊਟ ਹੋਣ ਲੱਗਦੀਆਂ ਹਨ। ਥੋੜ੍ਹੇ ਸਮੇਂ ਵਿਚ, ਇੱਥੋਂ ਤੱਕ ਕਿ ਉਹ ਪੇਜ ਵੀ ਜਿਨ੍ਹਾਂ ਨੂੰ ਬਾਹਰੀ API ਦੀ ਲੋੜ ਨਹੀਂ, ਉਹ ਵੀ ਟੁੱਟੇ ਹੋਏ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਸਿਸਟਮ ਉਡੀਕ ਵਾਲੇ ਕੰਮ ਨਾਲ ਭਰ ਗਿਆ ਹੈ।

ਇਸਦਾ ਪ੍ਰਭਾਵ ਸਪਸ਼ਟ ਹੈ। ਇੱਕ ਖਟਾਪਟ identity provider ਸਾਈਨਅਪ ਅਤੇ ਲੌਗਿਨ ਰੋਕ ਸਕਦਾ ਹੈ। ਇੱਕ payment gateway ਟਾਈਮਆਊਟ checkout ਨੂੰ ਜ਼ਾਮ ਕਰ ਦਿੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਯੂਜ਼ਰ ਨੂੰ ਪਤਾ ਨਹੀਂ ਰਹਿੰਦਾ ਕਿ ਉਨ੍ਹਾਂ ਤੋਂ ਪੈਸਾ ਕੱਟਿਆ ਗਿਆ ਹੈ ਜਾਂ ਨਹੀਂ। ਇੱਕ ਮੈਸੇਜਿੰਗ ਦੇਰੀ password reset ਅਤੇ order confirmations ਰੋਕ ਸਕਦੀ है, ਜੋ ਦੂਜੇ ਲਹਿਰ ਦੇ ਰੀਟ੍ਰਾਈ ਅਤੇ ਸਹਾਇਤਾ ਟਿਕਟਾਂ ਦਾ ਕਾਰਨ ਬਣਦੀ ਹੈ।

ਉਦੇਸ਼ ਸਧਾਰਨ ਹੈ: ਬਾਹਰੀ ਫੇਲਯਰਾਂ ਨੂੰ ਅਲੱਗ ਕਰੋ ਤਾਂ ਕਿ ਮੁੱਖ ਵਰਕਫਲੋ ਚਲਦੇ ਰਹਿਣ। ਇਹ ਦਾ ਮਤਲਬ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਯੂਜ਼ਰ ਨੂੰ ਆਰਡਰ place ਕਰਨ ਦਿਓ ਅਤੇ ਬਾਅਦ ਵਿੱਚ payment ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਜਾਂ signup ਦੀ ਆਗਿਆ ਦਿਓ ਭਾਵੇਂ welcome email fail ਹੋ ਜਾਵੇ।

ਇੱਕ ਪ੍ਰਾਇਗਮੈਟਿਕ ਸਫਲਤਾ ਮੈਟ੍ਰਿਕ: ਜਦੋਂ ਕੋਈ ਪ੍ਰੋਵਾਇਡਰ ਸੁਸਤ ਜਾਂ ਡਾਊਨ ਹੋਵੇ, ਤਾਂ ਤੁਹਾਡੀ ਐਪ ਫਿਰ ਵੀ ਤੇਜ਼ ਅਤੇ ਸਪਸ਼ਟ ਜਵਾਬ ਦੇਵੇ, ਅਤੇ ਨੁਕਸਾਨ ਦਾ ਦਾਇਰਾ ਛੋਟਾ ਰਹੇ। ਉਦਾਹਰਣ ਲਈ, ਜ਼ਿਆਦਾਤਰ ਮੁੱਖ ਰਿਕਵੇਸਟਾਂ ਅਜੇ ਵੀ ਆਮ ਲੈਟੇੰਸੀ ਬਜਟ ਵਿੱਚ ਖਤਮ ਹੁੰਦੀਆਂ ਹਨ, ਫੇਲ੍ਹਰ ਉਹੀ ਫੀਚਰ ਸੀਮਿਤ ਰਹਿੰਦੇ ਹਨ ਜੋ ਇਸ API 'ਤੇ ਨਿਰਭਰ ਹਨ, ਯੂਜ਼ਰ ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਸਥਿਤੀ (queued, pending, try again later) ਦਿਖਾਈ ਦੇਵੇ, ਅਤੇ ਜਦੋਂ ਪ੍ਰੋਵਾਇਡਰ ਵਾਪਸ ਆਏ ਤਾਂ ਰਿਕਵਰੀ ਆਪਮੈਟਿਕ ਹੋ ਜਾਵੇ।

ਉਹ ਫੇਲਯਰ ਮੋਡ ਜਿਨ੍ਹਾਂ ਲਈ ਤੁਸੀਂ ਤਿਆਰ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ

ਜ਼ਿਆਦਾਤਰ ਫੇਲਯਰ ਅਣੁਮਾਨਯੋਗ ਹੁੰਦੇ ਹਨ, ਭਾਵੇਂ ਉਨ੍ਹਾਂ ਦਾ ਸਮਾਂ ਅਣਜਾਣ ਹੋਵੇ। ਉਨ੍ਹਾਂ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਨਾਂ ਦਿਓ ਅਤੇ ਫਿਰ ਤੁਸੀਂ ਫੈਸਲਾ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਕੀ ਰੀਟ੍ਰਾਈ ਕਰਨਾ ਹੈ, ਕੀ ਬੰਦ ਕਰਨਾ ਹੈ, ਅਤੇ ਯੂਜ਼ਰ ਨੂੰ ਕੀ ਦਿਖਾਉਣਾ ਹੈ।

ਆਮ ਸ਼੍ਰੇਣੀਆਂ:

• ਲੈਟੈਂਸੀ ਸਪਾਈਕ (ਰਿਕਵੇਸਟਾਂ ਅਚਾਨਕ 10x ਲੰਬੀਆਂ ਹੋ ਜਾਣ)
• ਟ੍ਰਾਂਜ਼ੀਐਂਟ ਸਰਵਰ ਜਾਂ ਨੈਟਵਰਕ ਐਰਰ (ਟਾਈਮਆਊਟ, 502/503, ਕਨੈਕਸ਼ਨ ਰੀਸੈਟ)
• ਰੇਟ ਲਿਮਿਟ ਅਤੇ ਕੋਟਾ ਖਤਮ ਹੋਣਾ (429s, ਦੈਨਿਕ caps)
• ਅਥਾਰਟੀ ਅਤੇ ਪਰਮਿਸ਼ਨ ਸਮੱਸਿਆਵਾਂ (expired keys, revoked access)
• ਖਰਾਬ ਜਾਂ ਹੈਰਾਨ کن ਮਾਹੀਅਤ (missing fields, ਗਲਤ ਫਾਰਮੈਟ, ਅਧੂਰੇ ਜਵਾਬ)

ਸਭ ਐਰਰ ਇੱਕੋ ਜਿਹੇ ਨਹੀਂ ਹੁੰਦੇ। ਟ੍ਰਾਂਜ਼ੀਐਂਟ ਮੁੱਦੇ ਆਮ ਤੌਰ 'ਤੇ retry ਕਰਨ ਦੇ ਯੋਗ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਅਗਲੀ ਕੋਸ਼ਿਸ਼ ਸਫਲ ਹੋ ਸਕਦੀ ਹੈ (ਨੈਟਵਰਕ ਬਲਿਪ, ਟਾਈਮਆਊਟ, 502/503, ਅਤੇ ਕੁਝ 429s ਜੇ ਇੰਤਜ਼ਾਰ ਕੀਤਾ ਜਾਵੇ)। ਸਥਾਈ ਮੁੱਦੇ ਆਮਤੌਰ 'ਤੇ ਆਪਣੇ ਆਪ ਠੀਕ ਨਹੀਂ ਹੁੰਦੇ (invalid credentials, ਗਲਤ endpoints, malformed requests, permission denials)।

ਹਰ ਐਰਰ ਨੂੰ ਇੱਕੋ ਜਿਹਾ ਵਰਤਾਉ ਕਰਨਾ ਇੱਕ ਛੋਟੀ ਘਟਨਾ ਨੂੰ ਡਾਊਨਟਾਈਮ ਵਿੱਚ ਬਦਲ ਦੇਂਦਾ ਹੈ। ਸਥਾਈ ਫੇਲਯਰਾਂ ਨੂੰ ਰੀਟ੍ਰਾਈ ਕਰਨਾ ਸਮਾਂ ਖਰਚ ਕਰਦਾ ਹੈ, ਰੇਟ ਲਿਮਿਟ ਤੇਜ਼ੀ ਨਾਲ ਛੂਹਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਪਿਛੋਕੜ ਬਣਦਾ ਹੈ ਜੋ ਹੋਰ ਸਭ ਕੁਝ ਧੀਮਾ ਕਰ ਦਿੰਦਾ ਹੈ। ਕਦੇ ਵੀ ਟ੍ਰਾਂਜ਼ੀਐਂਟ ਫੇਲ੍ਯਰਾਂ ਨੂੰ ਰੀਟ੍ਰਾਈ ਨਾ ਕਰਨ ਨਾਲ ਯੂਜ਼ਰਾਂ ਨੂੰ ਦੋਹਰਾਈ ਕਰਨ ਲਈ ਮਜ਼ਬੂਰ ਕਰਦਾ ਹੈ ਅਤੇ ਉਹ ਕੰਮ ਗੁੰਮ ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਕੁਝ ਪਲਾਂ ਵਿੱਚ ਮੁਕੰਮਲ ਹੋ ਸਕਦਾ ਸੀ।

ਉਨ੍ਹਾਂ ਵਰਕਫਲੋਜ਼ 'ਤੇ ਵੱਖ-ਵੱਖ ਧਿਆਨ ਦਿਓ ਜਿੱਥੇ ਇੱਕ ਰੁਕਾਵਟ ਟੁੱਟ ਜਾਣ ਵਰਗੀ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ: checkout, login, password reset, ਅਤੇ notifications (email/SMS/push)। ਇੱਕ marketing API ਵਿੱਚ 2 ਸੈਕਿੰਡ ਦਾ ਸਪਾਈਕ ਉਬਲੇ ਪੱਗੇ ਹੈ, ਪਰ payment authorization ਵਿੱਚ 2 ਸੈਕਿੰਡ ਦਾ ਸਪਾਈਕ ਰੈਵੇਨਿਊ ਰੋਕ ਸਕਦਾ ਹੈ।

ਇੱਕ ਮਦਦਗਾਰ ਟੈਸਟ: "ਕੀ ਇਹ ਕਾਲ ਵਰਤੋਂਕਾਰ ਦੇ ਮੁੱਖ ਟਾਸਕ ਨੂੰ ਹੁਣੇ ਖਤਮ ਕਰਨ ਲਈ ਜ਼ਰੂਰੀ ਹੈ?" ਜੇ ਹਾਂ, ਤਾਂ ਤੁਹਾਨੂੰ ਸਖ਼ਤ timeouts, ਧਿਆਨ ਨਾਲ retries, ਅਤੇ ਸਪਸ਼ਟ failure path ਦੀ ਲੋੜ ਹੈ। ਜੇ ਨਹੀਂ, ਤਾਂ ਇਸਨੂੰ ਇੱਕ ਕਤਾਰ ਵਿੱਚ ਰੱਖੋ ਅਤੇ ਐਪ ਨੂੰ ਜਵਾਬਦੇਹ ਬਣਾਓ।

ਟਾਈਮਆਊਟ: ਇੱਕ ਸੀਮਾ ਚੁਣੋ ਅਤੇ ਉਹਦੇ ਨਾਲ ਬਣੇ ਰਹੋ

ਟਾਈਮਆਊਟ ਉਹ ਵਧੀਆਂ ਸਮਾਂ ਹੈ ਜੋ ਤੁਸੀਂ ਉਡੀਕ ਕਰਨ ਲਈ ਤਿਆਰ ਹੋ। ਸਾਫ ਸੀਮਾ ਦੇ ਬਿਨਾ, ਇੱਕ ਸੁਸਤ ਪ੍ਰੋਵਾਇਡਰ ਉਡੀਕ ਵਾਲੀਆਂ ਰਿਕਵੇਸਟਾਂ ਨੂੰ ਇਕਠਾ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਅਹੰਕਾਰਿਕ ਕੰਮ ਨੂੰ ਰੋਕ ਦੇਵੇਗਾ।

ਇਹ ਦੋ ਕਿਸਮ ਦੀ ਉਡੀਕ ਨੂੰ ਵੱਖ-ਵੱਖ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ:

• Connect timeout: ਕਨੈਕਸ਼ਨ ਸਥਾਪਿਤ ਕਰਨ ਲਈ ਤੁਸੀਂ ਕਿੰਨਾ ਸਮਾਂ ਕੋਸ਼ਿਸ਼ ਕਰੋਗੇ।
• Read timeout: ਕਨੈਕਟ ਹੋਣ ਤੋਂ ਬਾਅਦ ਜਵਾਬ ਲਈ ਤੁਸੀਂ ਕਿੰਨਾ ਸਮਾਂ ਉਡੀਕ ਕਰੋਗੇ।

ਨੰਬਰ ਚੁਣਨਾ ਪਰਫੈਕਸ਼ਨ ਬਾਰੇ ਨਹੀਂ ਹੈ। ਇਹ ਮਨੁੱਖੀ ਧੀਰਜ ਅਤੇ ਤੁਹਾਡੇ ਵਰਕਫਲੋ ਨਾਲ ਮਿਲਾਉਣ ਬਾਰੇ ਹੈ।

• ਜੇ ਇੱਕ ਯੂਜ਼ਰ spinner ਦੇਖ ਰਿਹਾ ਹੈ, ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਨੂੰ ਇੱਕ ਤੇਜ਼ ਜਵਾਬ ਅਤੇ ਸਪਸ਼ਟ ਅਗਲਾ ਕਦਮ ਚਾਹੀਦਾ ਹੈ।
• ਜੇ ਇਹ ਪਿਛੋਕੜ ਦਾ ਜੌਬ ਹੈ (ਜਿਵੇਂ ਰਾਤ ਨੂੰ ਇਨਵੌਇਸ ਸਿੰਕ ਕਰਨਾ), ਤਾਂ ਤੁਸੀਂ ਜ਼ਿਆਦਾ ਸਮਾਂ ਦੇ ਸਕਦੇ ਹੋ, ਪਰ ਇਹ ਵੀ ਇੱਕ ਸੀਮਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਤਾਂ ਕਿ ਇਹ ਕਦੇ ਵੀ ਲੰਬੇ ਸਮੇਂ ਲਈ ਫੱਸ ਕੇ ਨਾ ਰਹੇ।

ਟਾਈਮਆਊਟ ਚੁਣਨ ਦਾ ਇੱਕ ਪ੍ਰਾਇਗਮੈਟਿਕ ਤਰੀਕਾ ਤਜਰਬੇ ਤੋਂ ਵਾਪਸ ਕੰਮ ਕਰਨਾ ਹੈ:

• ਇੱਕ ਯੂਜ਼ਰ ਕਿੰਨੇ ਸਮੇਂ ਉਡੀਕ ਕਰ ਸਕਦਾ ਹੈ ਨਾਲੋਂ ਤੁਹਾਨੂੰ ਸਪਸ਼ਟ ਸੁਨੇਹਾ ਦਿਖਾਉਣਾ ਚਾਹੀਦਾ ਹੈ?
• ਜੇ ਇਹ ਕਾਲ ਹੁਣ ਫੇਲ ਹੋਈ, ਕੀ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਰੀਟ੍ਰਾਈ ਕਰ ਸਕਦੇ ਹੋ ਜਾਂ fallback ਵਰਤ ਸਕਦੇ ਹੋ?
• peak ਲੋਡ ਤੇ ਇਹਨਾਂ ਕਾਲਾਂ ਦੀ ਗਿਣਤੀ ਕਿੰਨੀ ਹੈ?

ਟ੍ਰੇਡਅਫ਼ ਅਸਲ ਹੈ। ਹੋਰ ਦੇਰ ਕਰੋ ਅਤੇ ਤੁਸੀਂ ਥ੍ਰੈਡ, ਵਰਕਰ, ਅਤੇ ਡੀਬੀ ਕਨੈਕਸ਼ਨ ਜਬਤ ਕਰ ਲੈਂਦੇ ਹੋ। ਬਹੁਤ ਛੋਟਾ ਕਰੋ ਅਤੇ ਤੁਸੀਂ ਝੂਠੇ ਫੇਲ੍ਹਰ ਬਣਾਉਂਦੇ ਹੋ ਅਤੇ ਬੇਲੋੜੇ ਰੀਟ੍ਰਾਈਜ਼ ਨੂੰ ਟ੍ਰਿਗਰ ਕਰਦੇ ਹੋ।

ਰੀਟ੍ਰਾਈਜ਼ ਜੋ ਆਊਟੇਜ ਨੂੰ ਹੋਰ ਬੁਰਾ ਨਾ ਬਣਾਏ

ਰੀਟ੍ਰਾਈਜ਼ ਉਹਨਾਂ ਸਮਿਆਂ ਵਿੱਚ ਮਦਦਗਾਰ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਫੇਲ੍ਹਰ ਅਸਭਾਵਾ ਹੈ: ਇੱਕ ਛੋਟੀ ਨੈਟਵਰਕ ਸਮੱਸਿਆ, DNS ਬਲਿਪ, ਜਾਂ ਇੱਕ-ਵਾਰ 500/502/503। ਅਹਿਸੇ ਹਾਲਾਤਾਂ ਵਿੱਚ, ਦੁਸਰੀ ਕੋਸ਼ਿਸ਼ ਸਫਲ ਹੋ ਸਕਦੀ ਹੈ ਅਤੇ ਯੂਜ਼ਰ ਨੂੰ ਕੋਈ ਪਤਾ ਨਹੀਂ ਲੱਗਦਾ।

ਖਤਰਾ ਇੱਕ retry storm ਹੈ। ਜਦੋਂ ਬਹੁਤ ਸਾਰੇ ਕਲਾਇੰਟ ਇੱਕੇਸਾਰ ਫੇਲ ਹੁੰਦੇ ਹਨ ਅਤੇ ਸਾਰੇ ਇਕੱਠੇ ਰੀਟ੍ਰਾਈ ਕਰਦੇ ਹਨ, ਉਹ ਪ੍ਰੋਵਾਇਡਰ (ਅਤੇ ਤੁਹਾਡੇ ਆਪਣੇ ਵਰਕਰ) ਨੂੰ ਓਵਰਲੋਡ ਕਰ ਸਕਦੇ ਹਨ। Backoff ਅਤੇ jitter ਇਸਨੂੰ ਰੋਕਦੇ ਹਨ।

ਇੱਕ retry budget ਤੁਹਾਨੂੰ ਸਚਾ ਰੱਖਦਾ ਹੈ। ਕੋਸ਼ਿਸ਼ਾਂ ਘੱਟ ਰੱਖੋ ਅਤੇ ਕੁੱਲ ਸਮੇਂ ਨੂੰ ਸੀਮਿਤ ਕਰੋ ਤਾਂ ਕਿ ਮੁੱਖ ਵਰਕਫਲੋ ਕਿਸੇ ਹੋਰ ਉੱਤੇ ਉਡੀਕ ਕਰਨ ਲਈ ਫੱਸੇ ਨਾ।

ਇੱਕ ਸੁਰੱਖਿਅਤ ਡਿਫੌਲਟ ਰੀਟ੍ਰਾਈ ਰੇਸਿਪੀ

• ਕੇਵਲ ਕੁਝ ਵਾਰ ਰੀਟ੍ਰਾਈ ਕਰੋ (ਅਕਸਰ 1-3 ਕੋਸ਼ਿਸ਼ਾਂ ਕੁੱਲ, ਫਲੋ ਦੇ ਅਨੁਸਾਰ)।
• ਐਕਸਪੋਨੈਨਸ਼ੀਅਲ ਬੈਕਆਫ (ਉਦਾਹਰਣ: 200ms, 500ms, 1s) ਅਤੇ ਰੈਂਡਮ ਜਿਤਰ ਵਰਤੋ।
• ਰੀਟ੍ਰਾਈ ਕਰਨ 'ਤੇ ਲੱਗਣ ਵਾਲੇ ਕੁੱਲ ਸਮੇਂ ਨੂੰ ਕੈਪ ਕਰੋ (ਉਪਭੋਗਤਾ-ਸਮ੍ਹੀਤ ਫਲੋਜ਼ ਲਈ ਅਕਸਰ ਕੁਝ ਸਕਿੰਟ)।
• ਸਾਰੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਲਈ ਇਕ ਲੰਬੇ ਟਾਈਮਆਊਟ ਦੀ ਬਜਾਏ ਹਰ ਕੋਸ਼ਿਸ਼ ਲਈ ਪ੍ਰਤੀ-ਕੋਸ਼ਿਸ਼ timeout ਰੱਖੋ।

400/422 ਜਿਵੇਂ predictable client errors, 401/403 auth ਸਮੱਸਿਆਵਾਂ, ਜਾਂ 404s ਨੂੰ ਰੀਟ੍ਰਾਈ ਨਾ ਕਰੋ। ਇਹਾਂ ਮੁੱਢਲੇ ਹੀ ਮੁੜ ਫੇਲ ਹੋਣਗੇ ਅਤੇ ਸਿਰਫ ਲੋਡ ਵਧਾਉਂਦੇ ਹਨ।

ਇੱਕ ਹੋਰ ਗਾਰਡਰੇਲ: ਜਦੋਂ ਤੁਸੀਂ ਲਿਖਵਟ (POST/PUT) ਰੀਟ੍ਰਾਈ ਕਰਦੇ ਹੋ ਤਾਂ ਸਿਰਫ ਉਸ ਵੇਲੇ ਕਰੋ ਜਦੋਂ idempotency ਹੋਵੇ, ਨਹੀਂ ਤਾਂ ਤੁਸੀਂ ਡਬਲ ਚਾਰਜ ਜਾਂ ਡੁਪਲਿਕੇਟ ਰਿਕਾਰਡ ਦਾ ਖਤਰਾ ਲੈ ਰਹੇ ਹੋ।

ਇਡੇਮਪੋਟੈਂਸੀ: ਰੀਟ੍ਰਾਈਜ਼ ਨੂੰ ਅਸਲ ਵਰਕਫਲੋਜ਼ ਲਈ ਸੁਰੱਖਿਅਤ ਬਣਾਓ

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

ਚੈੱਕਆਉਟ ਦਾ ਕਲਪਨਾ ਕਰੋ: payment API ਸੁਸਤ ਹੈ, ਤੁਹਾਡੀ ਐਪ ਟਾਈਮਆਊਟ ਹੋ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਰੀਟ੍ਰਾਈ ਕਰਦੇ ਹੋ। ਜੇ ਪਹਿਲੀ ਕਾਲ ਅਸਲ ਵਿੱਚ ਸਫਲ ਰਹੀ ਸੀ, ਤਾਂ ਰੀਟ੍ਰਾਈ ਦੂਜੀ ਚਾਰਜ ਬਣਾਉ ਸਕਦੀ ਹੈ। ਇਹੀ ਖਤਰਾ ਆਰਡਰ ਬਣਾਉਣ, subscription ਸ਼ੁਰੂ ਕਰਨ, email/SMS ਭੇਜਣ, refund ਜਾਰੀ ਕਰਨ, ਜਾਂ support ਟਿਕਟ ਬਣਾਉਣ ਵਰਗੀਆਂ ਕਾਰਵਾਈਆਂ ਵਿੱਚ ਵੀ ਹੁੰਦਾ ਹੈ।

ਸੁਧਾਰ ਇਹ ਹੈ ਕਿ ਹਰ "ਕੁਝ ਕਰੋ" ਕਾਲ ਨਾਲ ਇੱਕ idempotency ਕੁੰਜੀ (ਜਾਂ request ID) ਜੁੜੀ ਹੋਵੇ। ਇਹ ਯੂਜ਼ਰ ਕਾਰਵਾਈ ਪ੍ਰਤੀ ਵਿਲੱਖਣ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਨਾ ਕਿ ਹਰ ਕੋਸ਼ਿਸ਼ ਲਈ। ਪ੍ਰੋਵਾਇਡਰ (ਜਾਂ ਤੁਹਾਡੀ ਆਪਣੀ ਸੇਵਾ) ਉਸ ਕੁੰਜੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਨਕਲੀਆਂ ਦੀ ਪਛਾਣ ਕਰਦਾ ਹੈ ਅਤੇ ਦੁਹਰਾਉਂਦੇ ਬਦਲੇ ਉਹੀ ਨਤੀਜਾ ਵਾਪਸ ਕਰਦਾ ਹੈ।

idempotency key ਨੂੰ ਏਕ header ਦੀ ਤਰ੍ਹਾਂ ਨਾ ਸੋਚੋ ਜੋ ਕੋਈ ਭੁੱਲ ਨਾ ਜਾਵੇ, ਇਸਨੂੰ ਡੇਟਾ ਮਾਡਲ ਦਾ ਹਿੱਸਾ ਸਮਝੋ।

ਇੱਕ ਪੈਟਰਨ ਜੋ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਟਿਕਦਾ ਹੈ

ਜਦੋਂ ਯੂਜ਼ਰ ਐਕਸ਼ਨ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ (ਉਦਾਹਰਣ ਲਈ, ਉਹ "Pay" 'ਤੇ ਕਲਿੱਕ ਕਰਦਾ ਹੈ), ਇੱਕ ਕੀ ਜਨਰੇਟ ਕਰੋ ਅਤੇ ਉਸਨੂੰ ਆਪਣੇ ਲੋਕਲ ਰਿਕਾਰਡ ਨਾਲ ਸਟੋਰ ਕਰੋ।

ਹਰ ਕੋਸ਼ਿਸ਼ 'ਤੇ:

• ਉਹੀ ਕੁੰਜੀ ਭੇਜੋ।
• ਪਰਿਣਾਮ (success response, failure code, charge ID) ਸਟੋਰ ਕਰੋ।
• ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਰਿਕਾਰਡ ਕੀਤਾ ਨਤੀਜਾ ਹੈ, ਤਾਂ ਫਿਰ ਉਹੀ ਨਤੀਜਾ ਵਾਪਸ ਕਰੋ ਬਜਾਏ ਕਿ ਕਾਰਵਾਈ ਦੁਹਰਾਈ ਜਾਵੇ।

ਜੇ ਤੁਸੀਂ ਅੰਦਰੂਨੀ ਕਾਲਾਂ ਲਈ "ਪ੍ਰੋਵਾਇਡਰ" ਹੋ, ਤਾਂ ਸਰਵਰ-ਸਾਈਡ ਵੀ ਇੱਕੋ ਵਰਤਾਰਾ ਲਾਗੂ ਕਰੋ।

ਸਰਕਿਟ ਬ੍ਰੇਕਰ: ਜਦੋਂ ਇੱਕ API ਫੇਲ ਹੋ ਰਿਹਾ ਹੋਵੇ, ਕਾਲਾਂ ਰੋਕ ਦਿਓ

ਸਰਕਿਟ ਬ੍ਰੇਕਰ ਇੱਕ ਸੇਫਟੀ ਸੁਇਚ ਵਾਂਗ ਹੈ। ਜਦੋਂ ਇੱਕ ਬਾਹਰੀ ਸਰਵਿਸ ਫੇਲ ਹੋਣ ਲੱਗਦੀ ਹੈ, ਤੁਸੀਂ ਥੋੜੇ ਸਮੇਂ ਲਈ ਉਸਨੂੰ ਕਾਲ ਕਰਨਾ ਰੋਕ ਦਿੰਦੇ ਹੋ ਤਾਂ ਕਿ ਹੋਰ ਬੇਫ਼ਾਇਦਾ ਬੇਨਤੀਆਂ ਨਾਂ ਪੈਣ।

ਸਰਕਿਟ ਬ੍ਰੇਕਰ ਆਮ ਤੌਰ 'ਤੇ ਤਿੰਨ ਸਥਿਤੀਆਂ ਰੱਖਦਾ ਹੈ:

• Closed: ਰਿਕਵੇਸਟ ਆਮ ਤੌਰ 'ਤੇ ਬਹਿੰਦੇ ਹਨ।
• Open: ਕਾਲਾਂ ਇੱਕ ਕੁੱਲ ਕੁਲਡਾਊਨ ਵਿੰਡੋ ਲਈ ਰੋਕ ਦਿੱਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।
• Half-open: ਕੁਲਡਾਊਨ ਤੋਂ ਬਾਅਦ ਥੋੜ੍ਹੀਆਂ ਟੈਸਟ ਕਾਲਾਂ ਪ੍ਰੋਵਾਇਡਰ ਦੇ ਠੀਕ ਹੋਣ ਦੀ ਜਾਂਚ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।

ਜਦੋਂ ਬ੍ਰੇਕਰ open ਹੋਵੇ, ਤਾਂ ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਕੁਝ ਪੇਸ਼ਗੋਇਆ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਜਿਵੇਂ ਕਿ address validation API signup ਸਮੇਂ ਡਾਊਨ ਹੋਵੇ, ਤਾਂ address ਨੂੰ accept ਕਰੋ ਅਤੇ ਬਾਅਦ ਵਿੱਚ review ਲਈ ਚਿਨ੍ਹਤ ਕਰੋ। ਜੇ payment risk check ਡਾਊਨ ਹੋਵੇ, ਤਾਂ ਆਰਡਰ ਨੂੰ manual review ਲਈ queue ਕਰੋ ਜਾਂ ਉਸ ਵਿਕਲਪ ਨੂੰ ਅਸਥਾਇੀ ਤੌਰ 'ਤੇ ਅਸਰ ਰੱਦ ਕਰ ਦਿਓ ਅਤੇ ਵਜਹ ਦਿਖਾਓ।

ਥਰੈਸ਼ਹੋਲਡ ਚੁਣੋ ਜੋ ਯੂਜ਼ਰ ਪ੍ਰਭਾਵ ਨਾਲ ਮਿਲਦੇ ਹਨ:

• ਲਗਾਤਾਰ ਐਰਰ (ਉਦਾਹਰਣ: ਇੱਕ ਦਫ਼ਾ ਵਿੱਚ 5 ਫੇਲ੍ਹਰ)
• ਛੋਟੀ ਵਿੰਡੋ ਵਿੱਚ ਉੱਚ ਫੇਲ੍ਹਰ ਰੇਟ
• ਕਈ ਸੁਸਤ ਜਵਾਬ (ਟਾਈਮਆਊਟ)
• ਖਾਸ ਸਥਿਤੀ ਕੋਡ (ਜਿਵੇਂ ਲਗਾਤਾਰ 503s)

ਕੁਲਡਾਊਨ ਛੋਟਾ ਰੱਖੋ (ਸਕਿੰਟ ਤੋਂ ਇੱਕ ਮਿੰਟ) ਅਤੇ half-open ਪ੍ਰੋਬ ਨੂੰ ਸੀਮਤ ਰੱਖੋ। ਮਕਸਦ ਪਹਿਲਾਂ ਮੁੱਖ ਵਰਕਫਲੋਜ਼ ਦੀ ਰੱਖਿਆ ਕਰਨਾ ਹੈ, ਫਿਰ ਤੇਜ਼ੀ ਨਾਲ ਰਿਕਵਰ ਹੋਣਾ।

ਫਾਲਬੈਕ ਅਤੇ ਕਤਾਰਾਂ: ਐਪ ਨੂੰ ਵਰਤਣਯੋਗ ਰੱਖੋ

ਜਦੋਂ ਇੱਕ ਬਾਹਰੀ API ਸੁਸਤ ਜਾਂ ਡਾਊਨ ਹੋਵੇ, ਤੁਹਾਡਾ ਉਦੇਸ਼ ਯੂਜ਼ਰ ਨੂੰ ਅੱਗੇ ਵਧਣ ਦੇ ਯੋਗ ਰੱਖਣਾ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇੱਕ Plan B ਹੋਵੇ ਜੋ ਸੱਚ ਦੱਸੇ ਕਿ ਕੀ ਹੋਇਆ।

ਫਾਲਬੈਕ: "ਚੰਗਾ-ਕਾਫ਼ੀ" ਅਨੁਭਵ ਚੁਣੋ

ਫਾਲਬੈਕ ਉਹ ਹੈ ਜੋ ਤੁਹਾਡੀ ਐਪ ਕਰਦੀ ਹੈ ਜਦ API ਸਮੇਂ 'ਤੇ ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦੀ। ਵਿਕਲਪਾਂ ਵਿੱਚ cached ਡੇਟਾ ਵਰਤਣਾ, degraded ਮੋਡ (ਗੈਰ-ਜਰੂਰੀ ਵਿਜੇਟ ਲੁਕਾਉਣ, ਑ਪਸ਼ਨਲ ਕਾਰਵਾਈਆਂ ਬੰਦ), ਯੂਜ਼ਰ ਤੋਂ ਮੈਨੂਅਲ ਦਰਜ ਕਰਵਾਉਣਾ (ਮੈਨੁਅਲ address entry), ਜਾਂ ਇੱਕ ਸਪਸ਼ਟ ਸੁਨੇਹਾ ਦਿਖਾਉਣਾ ਸ਼ਾਮਿਲ ਹਨ ਜਿਸ ਵਿੱਚ ਅਗਲਾ ਕਦਮ ਦਰਸਾਇਆ ਗਿਆ ਹੋਵੇ।

ਇਮਾਨਦਾਰ ਰਹੋ: ਨਹੀਂ ਦਿਖਾਓ ਕਿ ਕੁਝ ਮੁਕੰਮਲ ਹੋ ਗਿਆ ਜੇ ਇਹ ਨਹੀਂ ਹੋਇਆ।

ਕਤਾਰਾਂ: ਜੇ "ਹੁਣ" ਜ਼ਰੂਰੀ ਨਹੀਂ ਤਾਂ ਬਾਅਦ ਵਿੱਚ ਕਰੋ

ਜੇ ਕੰਮ ਯੂਜ਼ਰ ਰਿਕਵੇਸਟ ਅੰਦਰ ਮੁਕੰਮਲ ਹੋਣਾ ਜ਼ਰੂਰੀ ਨਹੀਂ, ਤਾਂ ਉਸ ਨੂੰ ਕਤਾਰ ਵਿੱਚ ਧੱਕੋ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਜਵਾਬ ਦਿਓ। ਆਮ ਉਮੀਦਵਾਰ: emails ਭੇਜਣਾ, CRM ਨੂੰ ਸਿੰਕ ਕਰਨਾ, ਰਿਪੋਰਟ ਬਣਾਉਣਾ, ਅਤੇ analytics events ਪੋਸਟ ਕਰਨਾ।

ਕੋਰ ਕਾਰਵਾਈਆਂ ਲਈ ਫੈਲ ਫਾਸਟ ਕਰੋ। ਜੇ ਇੱਕ API checkout (ਜਾਂ account creation) ਨੂੰ ਮੁਕੰਮਲ ਕਰਨ ਲਈ ਜ਼ਰੂਰੀ ਨਹੀਂ ਹੈ, ਤਾਂ ਰਿਕਵੇਸਟ ਨੂੰ ਰੋਕੋ ਨਹੀਂ। ਆਰਡਰ accept ਕਰੋ, ਬਾਹਰੀ ਕਾਲ ਨੂੰ queue ਕਰੋ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ reconcile ਕਰੋ। ਜੇ API ਲਾਜ਼ਮੀ ਹੈ (ਜਿਵੇਂ payment authorization), ਤਾਂ ਤੇਜ਼ੀ ਨਾਲ fail ਕਰੋ ਅਤੇ ਯੂਜ਼ਰ ਨੂੰ ਉਡੀਕ ਨਹੀਂ ਕਰਵਾਉ।

ਯੂਜ਼ਰ ਦੇਖਿਆ ਹੋਇਆ ਜਿਸ ਨਾਲ ਪਿਛੋਕੜ ਦੇ ਨੇੜੇ ਹੋਵੇ: ਇੱਕ ਸਪਸ਼ਟ ਸਥਿਤੀ (completed, pending, failed), ਇੱਕ ਵਾਅਦਾ ਜੋ ਤੁਸੀਂ ਰੱਖ ਸਕਦੇ ਹੋ (ਰਸੀਦ ਹੁਣ, ਪੁਸ਼ਟੀ ਬਾਅਦ), retry ਕਰਨ ਦਾ ਤਰੀਕਾ, ਅਤੇ UI ਵਿੱਚ ਇੱਕ ਵਿਜ਼ੀਬਲ ਰਿਕਾਰਡ (activity log, pending badge)।

ਰੇਟ ਲਿਮਿਟ ਅਤੇ ਲੋਡ: ਆਪਣੇ-ਦੁਆਰਾ ਪੈਦਾ ਕੀਤੇ ਫੇਲ੍ਹਰਾਂ ਤੋਂ ਬਚੋ

ਰੇਟ ਲਿਮਿਟ ਪ੍ਰੋਵਾਇਡਰ ਦਾ ਤਰੀਕਾ ਹੈ ਕਹਿਣ ਦਾ, "ਤੁਸੀਂ ਸਾਨੂੰ ਕਾਲ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਨਹੀਂ।" ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਉਹਨਾਂ ਨਾਲੋਂ ਜਲਦੀ ਟੱਕਰਾਓਗੇ ਜਿੰਨਾ ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ: ਟ੍ਰੈਫਿਕ ਸਪਾਈਕ, ਸਮਕਾਲੀ background jobs, ਜਾਂ ਇੱਕ ਬੱਗ ਜੋ errors 'ਤੇ ਲੂਪ ਕਰਦਾ ਹੈ।

ਸ਼ੁਰੂ ਕਰੋ ਇਸ ਨਾਲ ਕਿ ਤੁਸੀਂ ਕਿੰਨੀ ਰਿਕਵੇਸਟ ਬਣਾਉਂਦੇ ਹੋ ਉਸ ਨੂੰ ਕੰਟਰੋਲ ਕਰੋ। ਜੇ ਸੰਭਵ ਹੋਏ ਬੈਚ ਕਰੋ, ਸੁਰੱਖਿਅਤ ਹੋਣ 'ਤੇ 30-60 ਸਕਿੰਟ ਲਈ responses cache ਕਰੋ, ਅਤੇ client-ਸਾਈਡ ਤੇ throttle ਕਰੋ ਤਾਂ ਕਿ ਤੁਹਾਡੀ ਐਪ ਪ੍ਰੋਵਾਇਡਰ ਦੀ ਮਰਜ਼ੀ ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ ਨ ਕੱਢੇ।

ਜਦੋਂ ਤੁਹਾਨੂੰ 429 Too Many Requests ਮਿਲੇ, ਇਸਨੂੰ ਹੌਲੀ ਹੋ ਜਾਣ ਦਾ ਸੰਕੇਤ سمجھੋ।

• ਜੇ Retry-After ਦਿੱਤਾ ਗਿਆ ਹੈ ਤਾਂ ਉਸ ਦੀ ਇੱਜ਼ਤ ਕਰੋ।
• ਬਹੁਤ ਸਾਰੇ ਵਰਕਰ ਇੱਕੋ ਸਮੇਂ ਨਾ ਰੀਟ੍ਰਾਈ ਕਰਨ ਇਸ ਲਈ jitter ਜੋੜੋ।
• 429s ਲਈ retries ਨੂੰ ਕੈਪ ਕਰੋ ਤਾਂ ਕਿ ਅਨੰਤ ਲੂਪ ਨ ਬਣੇ।
• ਲਗਾਤਾਰ 429s 'ਤੇ ਹੋਰ ਅਗ੍ਰੈਸੀਵ ਬੈਕਆਫ ਕਰੋ।
• ਇਸਨੂੰ ਇੱਕ ਮੈਟ੍ਰਿਕ ਵਜੋਂ ਰਿਕਾਰਡ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਯੂਜ਼ਰਾਂ ਤੋਂ ਪਹਿਲਾਂ ਪੈਟਰਨ ਦੇਖ ਸਕੋ।

ਇਸਦੇ ਨਾ ਨਾਲ concurrency ਨੂੰ ਵੀ ਸੀਮਿਤ ਕਰੋ। ਇੱਕ ਇਕੱਲਾ ਵਰਕਫਲੋ (ਜਿਵੇਂ contacts ਸਿੰਕ ਕਰਨਾ) ਸਾਰੇ worker slot ਖਾ ਕੇ critical flows ਜਿਵੇਂ login ਜਾਂ checkout ਨੂੰ ਭੁੱਖਾ ਨਹੀਂ ਰੱਖਣਾ ਚਾਹੀਦਾ। ਵੱਖ-ਵੱਖ ਪੂਲ ਜਾਂ per-feature caps ਮਦਦਗਾਰ ਹਨ।

ਕਦਮ-ਦਰ-ਕਦਮ: ਇੱਕ ਸੁਰੱਖਿਅਤ ਡਿਫੌਲਟ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਰੇਸੀਪੀ

ਹਰ ਤੀਜੇ-ਪੱਖ ਕਾਲ ਲਈ ਫੇਲ੍ਹਰ ਦੀ ਯੋਜਨਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਤੁਹਾਨੂੰ ਪਰਫੈਕਸ਼ਨ ਦੀ ਲੋੜ ਨਹੀਂ; ਤੁਹਾਨੂੰ predictable ਬਿਹੈਵਿਯਰ ਦੀ ਲੋੜ ਹੈ ਜਦੋਂ ਪ੍ਰੋਵਾਇਡਰ ਦਾ ਦਿਨ ਖਰਾਬ ਹੋਵੇ।

1) ਕਾਲ ਨੂੰ ਵਰਗੀਕਰਣ ਕਰੋ (must-have ਵਿਰੁੱਧ can-wait)

ਫੈਸਲਾ ਕਰੋ ਕਿ ਜੇ ਕਾਲ ਹੁਣ ਫੇਲ ਹੋ ਜਾਵੇ ਤਾਂ ਕੀ ਹੋਵੇਗਾ। ਚੈਕਆਉਟ ਦੌਰਾਨ ਟੈਕਸ ਕੈਲਕुलेਸ਼ਨ ਮਸ਼ਤੀ-ਹੈਵ ਹੋ ਸਕਦੀ ਹੈ। ਮਾਰਕੀਟਿੰਗ contact sync ਆਮਤੌਰ 'ਤੇ ਉਡੀਕ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਚੋਣ ਬਾਕੀ ਸਭ ਲਈ ਦਿਸ਼ਾ ਨਿਰਦੇਸ਼ ਨਿਰਧਾਰਿਤ ਕਰਦੀ ਹੈ।

2) ਟਾਈਮਆਊਟ ਅਤੇ ਰੀਟ੍ਰਾਈ ਬਜਟ ਸੈੱਟ ਕਰੋ

ਕਾਲ ਟਾਈਪ ਪ੍ਰਤੀ ਟਾਈਮਆਊਟ ਚੁਣੋ ਅਤੇ ਇਹਨਾਂ ਨੂੰ ਥਾਪੜ ਰੱਖੋ। ਫਿਰ ਇੱਕ retry budget ਰੱਖੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਧੀਰੇ-ਧੀਰੇ ਇੱਕ ਸੁਸਤ API 'ਤੇ ਹਮਲੇ ਨਾ ਕਰਦੇ ਰਹੋ।

• Must-have, ਯੂਜ਼ਰ ਉਡੀਕ ਕਰ ਰਿਹਾ: ਛੋਟਾ timeout, 0-1 retry।
• Can-wait, background job: ਲੰਬਾ timeout, ਕੁਝ ਰੀਟ੍ਰਾਈਜ਼ ਬੈਕਆਫ ਨਾਲ।
• ਕਦੇ ਵੀ ਅਨੰਤ ਸਮੇਂ ਲਈ ਰੀਟ੍ਰਾਈ ਨਾ ਕਰੋ: ਪ੍ਰਤੀ ਟਾਸਕ ਕੁੱਲ ਸਮੇਂ ਨੂੰ ਕੈਪ ਕਰੋ।

3) idempotency ਅਤੇ ਟ੍ਰੈਕਿੰਗ ਨਾਲ ਰੀਟ੍ਰਾਈਜ਼ ਸੁਰੱਖਿਅਤ ਬਣਾਓ

ਜੇ ਇੱਕ ਰਿਕਵੇਸਟ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਬਣਾਉਂਦੀ ਹੈ ਜਾਂ ਪੈਸਾ ਚਾਰਜ ਕਰਦੀ ਹੈ, ਤਾਂ idempotency keys ਜੋੜੋ ਅਤੇ request record ਸਟੋਰ ਕਰੋ। ਜੇ payment request ਟਾਈਮਆਊਟ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਰੀਟ੍ਰਾਈ ਡਬਲ-ਚਾਰਜ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ। ਟ੍ਰੈਕਿੰਗ ਸਹਾਇਤਾ ਨੂੰ ਇਹ ਜਵਾਬ ਦੇਣ ਵਿੱਚ ਵੀ ਮਦਦ ਕਰਦੀ ਹੈ, "ਕੀ ਇਹ ਗਿਆ?"

4) ਸਰਕਿਟ ਬ੍ਰੇਕਰ ਅਤੇ fallback ਰਵੱਈਆ ਜੋੜੋ

ਜਦੋਂ ਐਰਰ ਵੱਧਣ ਲੱਗਦੇ ਹਨ, ਪ੍ਰੋਵਾਇਡਰ ਨੂੰ ਕਾਲ ਕਰਨਾ ਰੋਕ ਦਿਓ ਥੋੜ੍ਹੇ ਸਮੇਂ ਲਈ। Must-have ਕਾਲਾਂ ਲਈ, ਇੱਕ ਸਪਸ਼ਟ "Try again" ਰਸਤਾ ਦਿਖਾਓ। Can-wait ਕਾਲਾਂ ਲਈ ਕੰਮ ਨੂੰ ਕਤਾਰ ਵਿੱਚ ਰੱਖੋ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਪ੍ਰੋਸੈਸ ਕਰੋ।

5) ਬੁਨਿਆਦੀ ਮੋਨਿਟਰਿੰਗ ਜੋੜੋ

ਲੇਟੈਂਸੀ, ਐਰਰ ਰੇਟ, ਅਤੇ breaker open/close events ਟ੍ਰੈਕ ਕਰੋ। ਸਸਤੇ ਬਲਿਪਾਂ ਨਹੀਂ, ਪਰ sustained changes 'ਤੇ ਅਲਾਰਮ ਕਰੋ।

ਆਮ ਗਲਤੀਆਂ ਜੋ ਇੱਕ ਛੋਟੀ ਸਮੱਸਿਆ ਨੂੰ ਡਾਊਨਟਾਈਮ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ

ਜ਼ਿਆਦਾਤਰ API outage ਵੱਡੇ ਨਹੀਂ ਹੋਕੇ ਸ਼ੁਰੂ ਹੁੰਦੇ; ਉਹ ਇਸ ਲਈ ਵੱਡੇ ਬਣ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਤੁਹਾਡੀ ਐਪ ਸਭ ਤੋਂ ਬੁਰੇ ਢੰਗ ਨਾਲ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰਦੀ ਹੈ: ਉਹ ਬਹੁਤ ਲੰਬੇ ਸਮੇਂ ਉਡੀਕ ਕਰਦੀ ਹੈ, ਬਹੁਤ ਜ਼ਿਆਦਾ retry ਕਰਦੀ ਹੈ, ਅਤੇ ਉਹੀ ਵਰਕਰ ਜੋ ਹੋਰ ਸਭ ਚੀਜ਼ਾਂ ਚਲਾਉਂਦੇ ਹਨ ਉਹੀ ਫੱਸ ਜਾਂਦੇ ਹਨ।

ਇਹ ਪੈਟਰਨ cascades ਪੈਦਾ ਕਰਦੇ ਹਨ:

• ਹਰ ਫੇਲ੍ਹਰ ਨੂੰ ਰੀਟ੍ਰਾਈ ਕਰਨਾ, ਸਮੇਤ 4xx ਸਮੱਸਿਆਵਾਂ ਜਿਵੇਂ invalid requests, expired auth, ਜਾਂ missing permissions।
• ਬਹੁਤ ਲੰਬੇ timeouts ਸੈੱਟ ਕਰਨਾ "ਸੁਰੱਖਿਅਤ ਰਹਿਣ ਲਈ," ਜੋ ਚੁੱਪ ਚਾਪ ਥ੍ਰੈਡ, DB connections, ਜਾਂ job runners ਨੂੰ ਖਪਾ ਲੈਂਦੇ ਹਨ ਜਦ ਤੱਕ ਤੁਸੀਂ ਸਮਰੱਥਾ ਖਤਮ ਨਹੀਂ ਹੋ ਜਾਂਦੀ।
• idempotency ਕੀ ਬਿਨਾ create actions ਨੂੰ ਰੀਟ੍ਰਾਈ ਕਰਨਾ, ਜਿਸ ਨਾਲ ਡਬਲ ਚਾਰਜ, ਨਕਲੀ shipment, ਜਾਂ ਦੁਹਰਾਏ ਰਿਕਾਰਡ ਬਣ ਜਾਂਦੇ ਹਨ।
• ਗਲਤ ਤਰ੍ਹਾਂ ਕਨਫਿਗਰ ਕੀਤੇ ਸਰਕਿਟ ਬ੍ਰੇਕਰ ਜੋ ਕਦੇ ਵੀ ਰਿਕਵਰ ਨਹੀਂ ਹੁੰਦੇ ਜਾਂ ਤੇਜ਼ੀ ਨਾਲ ਖੁਲ੍ਹਦੇ-ਬੰਦ ਹੁੰਦੇ ਰਹਿੰਦੇ ਹਨ।
• partial outages ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਫੇਲ੍ਹਰ ਸਮਝਣਾ ਬਜਾਏ ਸਿਰਫ ਪ੍ਰਭਾਵਿਤ ਫੀਚਰ ਨੂੰ degrade ਕਰਨਾ।

ਛੋਟੇ ਠੀਕ-ਕਾਮ μεγάδες ਵੱਡੇ ਆਊਟੇਜ ਰੋਕ ਸਕਦੇ ਹਨ: ਕੇਵਲ ਉਹਨਾਂ ਐਰਰਾਂ ਨੂੰ ਰੀਟ੍ਰਾਈ ਕਰੋ ਜੋ ਅਸਥਾਈ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਹੈ (ਟਾਈਮਆਊਟ, ਕੁਝ 429s, ਕੁਝ 5xx) ਅਤੇ ਕੋਸ਼ਿਸ਼ਾਂ ਨੂੰ ਬੈਕਆਫ ਅਤੇ ਜਿਤਰ ਨਾਲ ਕੈਪ ਕਰੋ; ਟਾਈਮਆਊਟ ਛੋਟੇ ਅਤੇ ਇਰਾਦੇ ਵਾਲੇ ਰੱਖੋ; idempotency ਲਾਜ਼ਮੀ ਬਣਾਓ ਜੇ ਕੋਈ ਕਾਰਵਾਈ ਬਣਾਉਂਦੀ ਹੈ ਜਾਂ ਚਾਰਜ ਕਰਦੀ ਹੈ; ਅਤੇ partial outages ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ।

ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਤੇਜ਼ ਚੈੱਕਲਿਸਟ

ਪੈਦਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਫੇਲ੍ਹਰ ਸੋਚ ਨਾਲ ਇੱਕ ਤੇਜ਼ ਪਾਸ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਆਈਟਮ ਲਈ "ਹਾਂ" ਨਹੀਂ ਕਹਿ ਸਕਦੇ, ਤਾਂ ਇਸਨੂੰ core workflows (signup, checkout, ਜਾਂ messages ਭੇਜਣ) ਲਈ ਰਿਲੀਜ਼ ਰੋਕਣ ਵਾਲਾ ਸਮਝੋ।

• ਸਮੇਂ ਦੀਆਂ ਸੀਮਾਵਾਂ ਸਪਸ਼ਟ ਹਨ (connect timeout ਅਤੇ read/response timeout)।
• ਰੀਟ੍ਰਾਈਜ਼ ਸੀਮਤ ਹਨ (ਛੋਟਾ retry budget, backoff, jitter, ਅਤੇ ਕੁੱਲ ਸਮਾਂ cap)।
• ਰੀਟ੍ਰਾਈਜ਼ ਅਸਲ ਕਾਰਵਾਈਆਂ ਲਈ ਸੁਰੱਖਿਅਤ ਹਨ (idempotency keys ਜਾਂ ਸਪਸ਼ਟ dedupe ਜਾਂਚ)।
• ਇੱਕ ਬ੍ਰੇਕਰ ਅਤੇ ਇੱਕ Plan B (fallback, degraded mode, ਜਾਂ ਕਤਾਰ) ਹੈ।
• ਤੁਸੀਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਜਲਦੀ ਵੇਖ ਸਕਦੇ ਹੋ (latency, error rate, ਅਤੇ ਪ੍ਰੋਵਾਇਡਰ ਅਤੇ ਐਂਡਪੌਇੰਟ ਪ੍ਰਤੀ dependency health)।

ਜੇ payment provider ਟਾਈਮਆਊਟ ਹੋਣਾ ਸ਼ੁਰੂ ਕਰ ਦੇ, ਤਾਂ ਸਹੀ ਬਿਹੈਵਿਯਰ ਇਹ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: "checkout ਫਿਰ ਵੀ ਲੋਡ ਹੁੰਦਾ ਹੈ, ਯੂਜ਼ਰ ਨੂੰ ਸਪਸ਼ਟ ਸੁਨੇਹਾ ਮਿਲਦਾ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਸਦੀਵੀ ਤੌਰ 'ਤੇ ਘੁੰਮਦੇ ਨਹੀਂ ਰਹਿੰਦੇ," ਨਾ ਕਿ "ਸਭ ਕੁਝ ਉਸ ਤਕ ਰੁਕ ਜਾਂਦਾ ਹੈ ਜਦ ਤਕ ਉਹ ਟਾਈਮਆਊਟ ਨਾ ਕਰ ਲਏ।"

ਉਦਾਹਰਣ: ਜਦੋਂ ਇੱਕ ਪ੍ਰੋਵਾਇਡਰ ਫਲਾਕੀ ਹੋਵੇ ਤਾਂ checkout ਦੀ ਰੱਖਿਆ

ਕਲਪਨਾ ਕਰੋ ਇੱਕ checkout ਜਿਸ ਵਿੱਚ ਤਿੰਨ ਸੇਵਾਵਾਂ ਕਾਲ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ: payment API ਕਾਰਡ ਚਾਰਜ ਕਰਨ ਲਈ, tax API ਟੈਕਸ ਕੈਲਕੁਲੇਟ ਕਰਨ ਲਈ, ਅਤੇ email API ਰਸੀਦ ਭੇਜਣ ਲਈ।

payment ਕਾਲ ਹੀ ਇਕੱਲੀ ਹੈ ਜੋ synchronous ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। tax ਜਾਂ email ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਖਰੀਦ ਨੂੰ ਫਸਾਉਣ ਨਹੀਂ ਚਾਹੀਦੀਆਂ।

ਜਦੋਂ tax API ਸੁਸਤ ਹੋਵੇ

ਕਹੋ tax API ਕਈ ਵਾਰੀ 8 ਤੋਂ 15 ਸਕਿੰਟ ਲੈਂਦੀ ਹੈ। ਜੇ checkout ਉਡੀਕ ਕਰਦਾ ਹੈ, ਯੂਜ਼ਰ ਕਾਰਟ ਛੱਡ ਦੇਂਦੇ ਹਨ ਅਤੇ ਤੁਹਾਡੀ ਐਪ ਵਰਕਰ ਫੱਸ ਜਾਂਦੇ ਹਨ।

ਇੱਕ ਸੁਰੱਖਿਅਤ ਫਲੋ:

• ਇੱਕ hard timeout ਸੈੱਟ ਕਰੋ (ਉਦਾਹਰਣ ਲਈ 800ms ਤੋਂ 2s) ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ fail ਕਰੋ।
• ਸਿਰਫ ਇੱਕ ਵਾਰੀ ਰੀਟ੍ਰਾਈ ਕਰੋ, ਜੇ ਇਹ ਸੁਰੱਖਿਅਤ ਹੋਵੇ, jitter ਨਾਲ।
• ਜੇ timeout ਹੋ ਜਾਵੇ, ਤਾਂ cached rate ਜਾਂ ਖਰੀਦਦਾਰ ਦੇ ਖੇਤਰ ਲਈ last-known table ਵਰਤੋ।
• ਜੇ ਤੁਸੀਂ ਕਾਨੂੰਨੀ ਤੌਰ 'ਤੇ cached rates ਵਰਤ ਨਹੀਂ ਸਕਦੇ, ਤਾਂ ਆਰਡਰ ਨੂੰ "pending tax" ਬਣਾਕੇ ਰੱਖੋ ਅਤੇ recalculation ਨੂੰ queue ਕਰੋ।

ਨਤੀਜਾ: ਘੱਟ abandoned carts ਅਤੇ ਘੱਟ ਫੱਸੇ ਹੋਏ ਆਰਡਰ ਜਦ tax provider ਸੁਸਤ ਹੋਵੇ।

ਜਦੋਂ email API ਡਾਊਨ ਹੋਵੇ

ਰਸੀਦ email ਮਹੱਤਵਪੂਰਨ ਹੈ, ਪਰ ਇਹ ਕਦੇ ਵੀ payment capture ਨੂੰ ਰੋਕਣ ਨਹੀਂ ਚਾਹੀਦਾ। ਜੇ email API ਫੇਲ ਕਰ ਰਿਹਾ ਹੈ, ਤਾਂ ਕੁਝ ਛੋਟੇ ਫੇਲ੍ਹਰਾਂ ਤੋਂ ਬਾਅਦ ਸਰਕਿਟ ਬ੍ਰੇਕਰ open ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ calls ਨੂੰ ਇੱਕ ਛੋਟੀ ਕੁਲਡਾਊਨ ਵਿੰਡੋ ਲਈ ਰੋਕ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ।

ਇਨਲਾਈਨ email ਭੇਜਣ ਦੀ ਬਜਾਏ, ਇੱਕ "send receipt" ਜੌਬ ਕਤਾਰ ਵਿੱਚ ਰੱਖੋ ਜਿਸ ਨਾਲ idempotency key (ਉਦਾਹਰਣ order_id + email_type) ਹੋਵੇ। ਜੇ ਪ੍ਰੋਵਾਇਡਰ ਡਾਊਨ ਹੋਵੇ, ਤਾਂ ਕਤਾਰ ਬੈਕਗ੍ਰਾਊਂਡ ਵਿੱਚ retry ਕਰਦੀ ਰਹੇਗੀ ਅਤੇ ਗਾਹਕ ਨੂੰ ਫਿਰ ਵੀ ਇੱਕ ਸਫਲ ਖਰੀਦ ਦਿੱਖੇਗੀ।

ਨਤੀਜਾ: ਘੱਟ ਸਹਾਇਤਾ ਟਿਕਟਾਂ ਗੁੰਮ ਰਸੀਦਾਂ ਲਈ, ਅਤੇ ਕਿਸੇ ਗੈਰ-ਭੁਗਤਾਨ ਕਾਰਨ checkout ਫੇਲ ਨਹੀਂ ਹੋ ਰਿਹਾ।

ਅਗਲੇ ਕਦਮ: ਆਪਣੇ ਐਪ ਵਿੱਚ ਇਹ ਸੁਰੱਖਿਆ धीरे-धीरे ਰੋਲਆਉਟ ਕਰੋ

ਇੱਕ workflow ਚੁਣੋ ਜਿਸਦਾ ਟੁੱਟਣਾ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਨੁਕਸਾਨ ਕਰਦਾ ਹੈ (checkout, signup, invoicing) ਅਤੇ ਉਸਨੂੰ ਆਪਣਾ reference integration ਬਣਾਓ। ਫਿਰ ਉਹੀ ਡਿਫੌਲਟ ਹਰ ਥਾਂ ਲਗਾਓ।

ਇੱਕ ਸਧਾਰਨ rollout ਕ੍ਰਮ:

• ਟਾਈਮਆਊਟ ਸੈੱਟ ਕਰੋ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ fail ਦਿਖਾਉ।
• backoff ਨਾਲ ਰੀਟ੍ਰਾਈ ਜੋੜੋ, ਪਰ ਸਿਰਫ retryable errors ਲਈ।
• idempotency ਜੋੜੋ ਤਾਂ ਕਿ ਰੀਟ੍ਰਾਈਜ਼ ਡਬਲ-ਚਾਰਜ ਨਾ ਕਰਨ।
• ਸਰਕਿਟ ਬ੍ਰੇਕਰ ਜੋੜੋ ਤਾਂ ਕਿ ਇੱਕ ਖਰਾਬ ਪ੍ਰੋਵਾਇਡਰ ਤੁਸੀਂ ਦੇ ਮੁੱਖ ਵਰਕਫਲੋ ਨੂੰ ਫਸਾ ਨਾ ਸਕੇ।

ਆਪਣੇ ਡਿਫੌਲਟ ਲਿਖੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਬੋਰਿੰਗ ਰੱਖੋ: ਇੱਕ connect timeout, ਇੱਕ request timeout, max retry count, backoff limit, breaker cooldown, ਅਤੇ retryable ਦੇ ਨਿਯਮ।

ਅਗਲੇ workflow ਵੱਲ ਵਧਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ failure drill ਚਲਾਓ। ਟੈਸਟ ਮਾਹੌਲ ਵਿੱਚ timeouts ਨੂੰ ਜਬਰਦਸਤੀਆਂ (ya provider ਨੂੰ ਅਵਰੋਧ) ਕਰੋ, ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਯੂਜ਼ਰ ਨੂੰ ਇੱਕ ਉਪਯੋਗ ਸਨੇਹਾ ਮਿਲਦਾ ਹੈ, fallback ਰਸਤੇ ਕੰਮ ਕਰਦੇ ਹਨ, ਅਤੇ queued retries ਹਮੇਸ਼ਾ ਲਈ ਇਕੱਠੇ ਨਹੀਂ ਹੋ ਰਹੇ।

ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਨਵੇਂ ਪ੍ਰੋਡਕਟ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਵਿਕਲਪਯੋਗ ਹੈ ਕਿ ਇਹ ਰਿਲਾਇਬਿਲਟੀ ਡਿਫੌਲਟ ਇੱਕ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਟੈਮਪਲੇਟ ਵਿੱਚ ਤਬਦੀਲ ਕੀਤੇ ਜਾਣ। ਟੀਮਾਂ ਲਈ ਜੋ Koder.ai (Koder.ai) ਵਰਤ ਰਹੀਆਂ ਹਨ, ਅਕਸਰ ਇਸਦਾ ਮਤਲਬ ਹੁੰਦਾ ਹੈ timeout, retry, idempotency, ਅਤੇ breaker ਨਿਯਮ ਇੱਕ ਵਾਰੀ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ, ਫਿਰ ਨਵੀਆਂ ਸੇਵਾਵਾਂ 'ਤੇ ਉਹੋ ਪੈਟਰਨ ਲਗਾਓ।