𝗪𝗵𝘆 𝗜 𝗦𝘁𝗼𝗽𝗽𝗲𝗱 𝗥𝗲𝗹𝘆𝗶𝗻𝗴 𝗼𝗻 𝗮 𝗦𝗶𝗻𝗴𝗹𝗲 𝗔𝗜 𝗣𝗿𝗼𝘃𝗶𝗱𝗲𝗿
ਮੈਂ ਇੱਕ ਕਮਿਊਨਿਟੀ ਫੋਰਮ ਲਈ ਇੱਕ ਰੀਅਲ-ਟਾਈਮ ਚੈਟਬੋਟ ਬਣਾਇਆ। ਮੈਨੂੰ ਲੱਗਿਆ ਕਿ ਸਿਰਫ਼ ਇੱਕ API ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਕਾਫ਼ੀ ਹੋਵੇਗਾ। ਮੈਂ ਗਲਤ ਸੀ।
ਤਿੰਨ ਹਫ਼ਤਿਆਂ ਬਾਅਦ, ਪੀਕ ਆਵਰਜ਼ (peak hours) ਦੌਰਾਨ ਮੈਨੂੰ 5xx ਐਰਰ ਆਇਆ। ਮੇਰਾ ਚੈਟਬੋਟ ਬੰਦ ਹੋ ਗਿਆ। ਯੂਜ਼ਰ ਨਿਰਾਸ਼ ਸਨ। ਮੈਨੂੰ ਅਹਿਸਾਸ ਹੋਇਆ ਕਿ ਮੈਂ ਪ੍ਰੋਡਕਸ਼ਨ ਐਪਸ ਲਈ ਸਿਰਫ਼ ਇੱਕ ਪ੍ਰੋਵਾਈਡਰ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰ ਸਕਦਾ।
ਮੈਂ GPT-4 ਦੀ ਵਰਤੋਂ ਕੀਤੀ। ਇਹ ਉਦੋਂ ਤੱਕ ਵਧੀਆ ਚੱਲਿਆ ਜਦੋਂ ਤੱਕ ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਆਈ। ਮੈਨੂੰ ਰੇਟ ਲਿਮਿਟਸ (rate limits), ਟਾਈਮਆਊਟਸ (timeouts) ਅਤੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਰਵਰ ਡਾਊਨ ਹੋਣ ਵਰਗੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ। ਉੱਚੇ ਟਾਇਰਾਂ (higher tiers) ਲਈ ਭੁਗਤਾਨ ਕਰਨਾ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਬਜਾਏ ਸਿਰਫ਼ ਉਸਦੇ ਲੱਛਣਾਂ ਨੂੰ ਠੀਕ ਕਰਨ ਵਰਗਾ ਲੱਗ ਰਿਹਾ ਸੀ।
ਮੈਂ ਹੋਰ ਪ੍ਰੋਵਾਈਡਰਾਂ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ, ਪਰ ਸਾਰਿਆਂ ਦੇ ਫਾਰਮੈਟ ਅਤੇ ਅਥੈਂਟੀਕੇਸ਼ਨ (auth) ਮੈਥਡ ਵੱਖਰੇ ਸਨ। ਮੇਰਾ ਕੋਡ switch-case ਸਟੇਟਮੈਂਟਾਂ ਦਾ ਇੱਕ ਜਾਲ ਬਣ ਗਿਆ। ਮੈਨੂੰ ਇੱਕ ਅਜਿਹੇ ਸਿਸਟਮ ਦੀ ਲੋੜ ਸੀ ਜੋ:
- ਪ੍ਰੋਵਾਈਡਰਾਂ ਦੇ ਅੰਤਰਾਂ ਨੂੰ ਲੁਕਾ ਸਕੇ।
- ਫੇਲ ਹੋਣ 'ਤੇ ਬੈਕਅੱਪ ਪ੍ਰੋਵਾਈਡਰ 'ਤੇ ਸਵਿਚ ਕਰ ਸਕੇ।
- ਰਿਸਪਾਂਸਾਂ ਨੂੰ ਕੈਸ਼ (cache) ਕਰ ਸਕੇ।
- ਵੈਂਡਰ ਲੌਕ-ਇਨ (vendor lock-in) ਤੋਂ ਬਚ ਸਕੇ।
ਮੈਂ Third-party ਲਾਇਬ੍ਰੇਰੀਆਂ ਤੋਂ ਬਚਿਆ ਕਿਉਂਕਿ ਉਹ ਬਹੁਤ ਗੁੰਝਲਦਾਰ ਸਨ ਅਤੇ ਆਸਾਨੀ ਨਾਲ ਖਰਾਬ ਹੋ ਜਾਂਦੀਆਂ ਸਨ। ਇਸ ਦੀ ਬਜਾਏ, ਮੈਂ ਇੱਕ ਸਧਾਰਨ ਰੂਟਰ (router) ਬਣਾਇਆ।
ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਮੈਂ ਸਾਰੇ ਪ੍ਰੋਵਾਈਡਰਾਂ ਲਈ ਇੱਕ ਸਾਂਝਾ ਇੰਟਰਫੇਸ (interface) ਤੈਅ ਕੀਤਾ। ਹਰੇਕ ਪ੍ਰੋਵਾਈਡਰ ਇੱਕ generate ਮੈਥਡ ਅਤੇ ਇੱਕ ਹੈਲਥ ਚੈੱਕ (health check) ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ।
ਅੱਗੇ, ਮੈਂ ਇੱਕ ਰੂਟਰ ਕਲਾਸ (router class) ਬਣਾਈ। ਇਹ ਇੱਕ ਖਾਸ ਕ੍ਰਮ ਵਿੱਚ ਪ੍ਰੋਵਾਈਡਰਾਂ ਨੂੰ ਅਜ਼ਮਾਉਂਦੀ ਹੈ। ਇਹ exponential backoff ਅਤੇ ਇੱਕ ਸਧਾਰਨ ਕੈਸ਼ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ। ਜੇਕਰ ਪਹਿਲਾ ਪ੍ਰੋਵਾਈਡਰ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਸਿਸਟਮ ਉਡੀਕ ਕਰਦਾ ਹੈ ਅਤੇ ਅਗਲੇ ਪ੍ਰੋਵਾਈਡਰ ਨੂੰ ਅਜ਼ਮਾਉਂਦਾ ਹੈ।
ਇਸ ਸਿਸਟਮ ਨੇ ਤਿੰਨ ਵੱਖ-ਵੱਖ ਆਊਟੇਜਾਂ (outages) ਦੌਰਾਨ ਮੇਰੇ ਵੀਕੈਂਡ ਬਚਾਏ। ਇਹ ਮੇਰੀ ਐਪ ਨੂੰ ਉਦੋਂ ਵੀ ਚਲਾਉਂਦਾ ਰਹਿੰਦਾ ਹੈ ਜਦੋਂ ਕੋਈ ਵੱਡਾ ਪ੍ਰੋਵਾਈਡਰ ਡਾਊਨ ਹੋ ਜਾਂਦਾ ਹੈ।
ਜੇਕਰ ਤੁਸੀਂ ਇਹ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਹਨਾਂ ਗੱਲਾਂ ਦਾ ਧਿਆਨ ਰੱਖੋ:
- ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਲੋਕਲ ਡਿਕਸ਼ਨਰੀ ਦੀ ਬਜਾਏ ਕੈਸ਼ਿੰਗ ਲਈ Redis ਦੀ ਵਰਤੋਂ ਕਰੋ।
- ਹੈਲਥ ਚੈੱਕ ਸਫਲਤਾ ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦੇ। ਇੱਕ ਪ੍ਰੋਵਾਈਡਰ ਚੈੱਕ ਪਾਸ ਕਰ ਸਕਦਾ ਹੈ ਪਰ ਅਸਲ ਰਿਕਵੈਸਟ ਫੇਲ ਹੋ ਸਕਦੀ ਹੈ।
- ਰੇਟ ਲਿਮਿਟਸ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਸੰਭਾਲਣ ਲਈ Retry-After ਹੈਡਰਾਂ ਨੂੰ ਪਾਰਸ (parse) ਕਰੋ।
- ਲਾਗਤਾਂ ਦਾ ਪਤਾ ਲਗਾਉਣ ਲਈ ਟੋਕਨ ਦੀ ਵਰਤੋਂ ਲਈ ਲੌਗਿੰਗ (logging) ਸ਼ਾਮਲ ਕਰੋ।
- ਉੱਚ ਪ੍ਰਦਰਸ਼ਨ ਲਈ asyncio ਦੀ ਵਰਤੋਂ ਕਰੋ।
ਜੇਕਰ ਤੁਹਾਡਾ ਪ੍ਰੋਜੈਕਟ ਛੋਟਾ ਹੈ, ਤਾਂ ਜ਼ਿਆਦਾ ਗੁੰਝਲਦਾਰ (over-engineer) ਨਾ ਬਣਾਓ। ਜੇਕਰ ਤੁਹਾਨੂੰ ਸਟ੍ਰੀਮਿੰਗ (streaming) ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਇਹ ਪੈਟਰਨ ਲੇਟੈਂਸੀ (latency) ਵਧਾ ਸਕਦਾ ਹੈ। ਆਪਣੇ ਪੱਧਰ ਅਨੁਸਾਰ ਸਹੀ ਟੂਲ ਚੁਣੋ।
ਤੁਸੀਂ ਪ੍ਰੋਵਾਈਡਰ ਦੀ ਭਰੋਸੇਯੋਗਤਾ ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲਦੇ ਹੋ? ਕੀ ਤੁਸੀਂ ਇੱਕ ਹੀ ਪ੍ਰੋਵਾਈਡਰ 'ਤੇ ਟਿਕੇ ਰਹਿੰਦੇ ਹੋ ਜਾਂ ਇੱਕ ਫਾਲਬੈਕ ਲੇਅਰ (fallback layer) ਬਣਾਉਂਦੇ ਹੋ?
Optional learning community: https://t.me/GyaanSetuAi