ਬਹੁ-ਕਿਰਾਏਦਾਰ SaaS ਪੈਟਰਨ: ਅਲੱਗਤਾ, ਸਕੇਲ ਅਤੇ AI ਡਿਜ਼ਾਈਨ

ਬਹੁ-ਕਿਰਾਏਦਾਰੀ ਦਾ ਅਰਥ (ਬਿਨਾਂ ਜਾਰਗਨ ਦੇ)

ਬਹੁ-ਕਿਰਾਏਦਾਰੀ ਦਾ ਮਤਲਬ ਹੈ ਇਕ ਹੀ ਚੱਲ ਰਹੇ ਸਿਸਟਮ ਤੋਂ ਇੱਕ ਸੌਫਟਵੇਅਰ ਉਤਪਾਦ ਕਈ ਗਾਹਕਾਂ (ਟੇਨੈਂਟਾਂ) ਨੂੰ ਸਰਵਿਸ ਕਰਦਾ ਹੈ। ਹਰ ਟੇਨੈਂਟ ਨੂੰ ਐਸਾ ਲੱਗਦਾ ਹੈ ਕਿ ਉਨ੍ਹਾਂ ਦੀ "ਆਪਣੀ ਐਪ" ਹੈ, ਪਰ ਪਿੱਛੇ ਦਾ ਢਾਂਚਾ—ਜਿਵੇਂ ਵੈੱਬ ਸਰਵਰ, ਕੋਡਬੇਸ ਅਤੇ ਅਕਸਰ ਡੇਟਾਬੇਸ—ਸ਼ੇਅਰ ਹੁੰਦੇ ਹਨ।

ਇੱਕ ਸਹਾਇਕ ਦਿਮਾਗੀ ਮਾਡਲ ਇੱਕ ਅਪਾਰਟਮੈਂਟ ਬਿਲਡਿੰਗ ਹੈ। ਹਰ ਕਿਸੇ ਕੋਲ ਆਪਣਾ ਬੰਦ ਯੂਨਿਟ ਹੁੰਦਾ ਹੈ (ਉਨ੍ਹਾਂ ਦਾ ਡੇਟਾ ਅਤੇ ਸੈਟਿੰਗਸ), ਪਰ ਤੁਸੀਂ ਬਿਲਡਿੰਗ ਦੀ ਲਿਫਟ, ਪਲੰਬਿੰਗ ਅਤੇ ਮੇਂਟਨੈਂਸ ਟੀਮ ਸਾਂਝੀ ਕਰਦੇ ਹੋ (ਐਪ ਦੀ ਕਮਪਿਊਟ, ਸਟੋਰੇਜ ਅਤੇ ਓਪਰੇਸ਼ਨ)।

ਟੀਮਾਂ ਬਹੁ-ਕਿਰਾਏਦਾਰ ਕਿਉਂ ਚੁਣਦੀਆਂ ਹਨ

ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਬਹੁ-ਕਿਰਾਏਦਾਰ SaaS ਇਸ ਲਈ ਨਹੀਂ ਚੁਣਦੀਆਂ ਕਿ ਇਹ ਫੈਸ਼ਨ ਹੈ—ਉਹ ਇਸ ਲਈ ਚੁਣਦੀਆਂ ਹਨ ਕਿ ਇਹ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੈ:

• ਹਰ ਗਾਹਕ ਦਾ ਘੱਟ ਲਾਗਤ: ਸਾਂਝੀ ਢਾਂਚਾ ਆਮ ਤੌਰ ਤੇ ਹਰ ਗਾਹਕ ਲਈ ਪੂਰਾ ਸਟੈਕ ਖੋਲ੍ਹਣ ਨਾਲੋਂ ਸਸਤਾ ਹੁੰਦਾ ਹੈ।
• ਸਰਲ ਓਪਰੇਸ਼ਨ: ਇੱਕ ਪਲੇਟਫਾਰਮ ਨੂੰ ਮਾਨੀਟਰ, ਪੈਚ ਅਤੇ ਸੁਰੱਖਿਅਤ ਕਰਨਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ (ਸੈਂਕੜਿਆਂ ਛੋਟੇ ਡਿਪਲੋਇਮੈਂਟਾਂ ਦੀ ਜਗ੍ਹਾ)।
• ਤੇਜ਼ ਡਿਲਿਵਰੀ: ਸੁਧਾਰ ਸਭ ਨੂੰ ਇਕੱਠੇ ਮਿਲਦੇ ਹਨ, ਅਤੇ ਤੁਸੀਂ ਗਾਹਕਾਂ ਕੇ ਬੀਚ "ਵਰਜ਼ਨ ਡ੍ਰਿਫਟ" ਤੋਂ ਬਚਦੇ ਹੋ।

ਕਿੱਥੇ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ

ਦੋ ਪ੍ਰਮੁੱਖ ਫੇਲਿਅਰ ਮੋਡ ਹਨ ਸੁਰੱਖਿਆ ਅਤੇ ਪਦਰਥਸ਼ੀਲਤਾ।

ਸੁਰੱਖਿਆ 'ਤੇ: ਜੇ ਟੇਨੈਂਟ ਬਾਉਂਡਰੀਆਂ ਹਰ ਥਾਂ ਪ੍ਰ-Enforce ਨਹੀਂ ਹੁੰਦੀਆਂ, ਤਾਂ ਇੱਕ ਬੱਗ ਡੇਟਾ ਲੀਕ ਕਰ ਸਕਦੀ ਹੈ। ਇਹ ਲੀਕ ਆਮ ਤੌਰ 'ਤੇ ਡਰਾਉਣ ਵਾਲੀ ਹੈਕਿੰਗ ਨਹੀਂ ਹੁੰਦੀਆਂ—ਜ਼ਿਆਦਾਤਰ ਆਮ ਗਲਤੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਜਿਵੇਂ ਗੁਮ ਹੋਇਆ ਫਿਲਟਰ, ਗਲਤ-ਕਨਫ਼ਿਗਰ ਕੀਤਾ ਪਰਮਿਸ਼ਨ ਚੈਕ, ਜਾਂ ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ ਜੋ ਟੇਨੈਂਟ ਸੰਦਰਭ ਬਿਨਾਂ ਚਲਦਾ ਹੈ।

ਪਦਰਥਸ਼ੀਲਤਾ 'ਤੇ: ਸਾਂਝੇ ਸਰੋਤਾਂ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇੱਕ ਵਿਆਸਤ ਟੇਨੈਂਟ ਹੋਰਾਂ ਨੂੰ ਸਲੋ ਕਰ ਸਕਦਾ ਹੈ। ਉਹ "ਨੋਇਜ਼ੀ ਨੇਬਰ" ਪ੍ਰਭਾਵ ਧੀਮੀ ਕ્વੈਰੀਜ਼, ਬਰਸਟ ਵਰਕਲੋਡ ਜਾਂ ਇੱਕ ਗਾਹਕ ਦੁਆਰਾ ਅਣੁਪਾਤੀ API ਖਪਤ ਵੱਗੇ ਦਿਖ ਸਕਦਾ ਹੈ।

ਇਸ ਲੇਖ ਵਿੱਚ ਦਰਸਾਏ ਪੈਟਰਨ ਦੀ ਛੋਟੀ ਜਲਕ

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

ਮੁੱਖ ਟਰੇਡ-ਆਫ਼: ਅਲੱਗਤਾ ਬਨਾਮ ਪ੍ਰਭਾਵਸ਼ੀਲਤਾ

ਬਹੁ-ਕਿਰਾਏਦਾਰੀ ਇਕ ਸੋਚ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਸ ਸਪੀਕਟਰਮ 'ਤੇ ਬੈਠਦੇ ਹੋ: ਟੇਨੈਂਟਾਂ ਵਿਚਕਾਰ ਕਿੰਨਾ ਸਾਂਝਾ ਕਰਦੇ ਹੋ ਬਨਾਮ ਹਰ ਟੇਨੈਂਟ ਲਈ ਕਿੰਨਾ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹੋ। ਹਰੇਕ ਆਰਕੀਟੈਕਚਰ ਪੈਟਰਨ ਹੇਠਾਂ ਇੱਕ ਇਸ ਲਾਈਨ ਦਾ ਵੱਖਰਾ ਨੁਕਤਾ ਹੈ।

ਸਾਂਝੇ ਬਨਾਮ ਨਿਰਧਾਰਤ ਸਰੋਤ: ਮੂਲ ਸਪੀਕਟਰਮ

ਇੱਕ ਪਾਸੇ, ਟੇਨੈਂਟ ਲਗਭਗ ਸਭ ਕੁਝ ਸਾਂਝਾ ਕਰਦੇ ਹਨ: ਇੱਕੋ ਹੀ ਐਪ ਇਨਸਟੈਂਸ, ਇੱਕੋ ਹੀ ਡੇਟਾਬੇਸ, ਇੱਕੋ ਹੀ ਕਿਊ, ਇੱਕੋ ਹੀ ਕੈਸ਼—ਟੇਨੈਂਟ ID ਅਤੇ ਐਕਸੈਸ ਨਿਯਮਾਂ ਨਾਲ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਵੱਖਰੇ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਸਸਤਾ ਅਤੇ ਚਲਾਉਣ ਵਿੱਚ ਆਸਾਨ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਕੈਪੈਸਿਟੀ ਪੂਲ ਕਰਦੇ ਹੋ।

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

ਅਲੱਗਤਾ ਅਤੇ ਲਾਗਤ ਕਿਉਂ ਵਿਰੋਧੀ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਖਿੱਚਦੇ ਹਨ

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

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

ਆਮ ਫੈਸਲੇ ਦੇ ਨਿਰਣਾਇਕ

ਤੁਹਾਡਾ "ਸਹੀ" ਸਥਾਨ ਫ਼ਿਲਾਸਫੀਕਲ ਨਹੀਂ—ਇਹ ਸੀਮਾਵਾਂ ਨਾਲ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ:

• SLA ਅਤੇ ਗਾਹਕ ਦੀਆਂ ਉਮੀਦਾਂ: ਕਠੋਰ ਅਪਟਾਈਮ ਜਾਂ ਲੈਟੈਂਸੀ ਟਾਰਗਟ ਵੱਧ ਅਲੱਗਤਾ ਵਲ ਧਕੇਲਦੇ ਹਨ।
• ਕੰਪਲਾਇੰਸ ਅਤੇ ਡੇਟਾ ਨਿਵਾਸ: ਲੋੜਾਂ ਨਿਰਧਾਰਿਤ ਸਟੋਰੇਜ ਜਾਂ ਨਿਰਧਾਰਤ ਵਾਤਾਵਰਣ ਮੰਗ ਸਕਦੀਆਂ ਹਨ।
• ਵਿਕਾਸ ਦਾ ਦਰਜਾ: ਸ਼ੁਰੂਆਤੀ ਉਤਪਾਦ ਤੇਜ਼ੀ ਲਈ ਅਕਸਰ ਸਾਂਝੇ ਹੁੰਦੇ ਹਨ; ਬਾਅਦ ਵਿੱਚ ਤੁਸੀਂ ਵੱਡੇ ਗਾਹਕਾਂ ਲਈ ਨਿਰਧਾਰਤ ਵਿਕਲਪ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹੋ।
• ਓਪਰੇਸ਼ਨਲ ਪੱਕਿਆਪਣ: ਵੱਧ ਅਲੱਗਤਾ ਆਮ ਤੌਰ 'ਤੇ ਵੱਧ ਮਾਨੀਟਰਿੰਗ, ਪੈਚ ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਮੰਗਦੀ ਹੈ।

ਪੈਟਰਨ ਚੁਣਨ ਲਈ ਇੱਕ ਸਧਾਰਨ ਦਿਮਾਗੀ ਮਾਡਲ

ਦੋ ਸਵਾਲ ਪੁੱਛੋ:

1. ਜੇ ਇੱਕ ਟੇਨੈਂਟ ਗਲਤ ਵਰਤਦਾ ਹੈ ਜਾਂ ਸੰਕਟ ਵਿੱਚ ਆ ਜਾਂਦਾ ਹੈ ਤਾਂ ਉਸ ਦਾ ਬਲਾਸਟ ਰੇਡੀਅਸ ਕੀ ਹੈ?

2. ਉਸ ਬਲਾਸਟ ਰੇਡੀਅਸ ਨੂੰ ਘਟਾਉਣ ਦੀ ਕਾਰੋਬਾਰੀ ਲਾਗਤ ਕੀ ਹੈ?

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

ਇੱਕ ਨਜ਼ਰ ਵਿੱਚ ਬਹੁ-ਕਿਰਾਏਦਾਰ ਮਾਡਲ

ਬਹੁ-ਕਿਰਾਏਦਾਰੀ ਇਕ ਹੀ ਆਰਕੀਟੈਕਚਰ ਨਹੀਂ—ਇਹ ਉਨ੍ਹਾਂ ਤਰੀਕਿਆਂ ਦਾ ਇੱਕ ਸੈੱਟ ਹੈ ਜਿਨ੍ਹਾਂ ਨਾਲ ਗਾਹਕਾਂ ਵਿਚਕਾਰ ਢਾਂਚਾ ਸਾਂਝਾ (ਜਾਂ ਨਾ) ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਸਭ ਤੋਂ ਵਧੀਆ ਮਾਡਲ ਇਹ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਕਿੰਨੀ ਅਲੱਗਤਾ ਦੀ ਲੋੜ ਹੈ, ਤੁਸੀਂ ਕਿੰਨੇ ਟੇਨੈਂਟ(expect) ਕਰਦੇ ਹੋ, ਅਤੇ ਤੁਹਾਡੀ ਟੀਮ ਕਿੰਨਾ ਓਪਰੇਸ਼ਨਲ ਓਵਰਹੈੱਡ ਸਹਿ ਸਕਦੀ ਹੈ।

1) ਸਿੰਗਲ-ਟੇਨੈਂਟ (ਨਿਰਧਾਰਤ) — ਬੇਸਲਾਈਨ

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

2) ਸਾਂਝੀ ਐਪ + ਸਾਂਝਾ DB — ਘੱਟੋ-ਘੱਟ ਲਾਗਤ, ਵੱਧ ਧਿਆਨ ਦੀ ਲੋੜ

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

3) ਸਾਂਝੀ ਐਪ + ਵੱਖਰਾ DB — ਮਜ਼ਬੂਤ ਅਲੱਗਤਾ, ਵੱਧ ਓਪਸ

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

4) "ਵੱਡੇ ਟੇਨੈਂਟ" ਲਈ ਹਾਈਬ੍ਰਿਡ ਮਾਡਲ

ਕਈ SaaS ਉਤਪਾਦ ਮਿਲੇ-ਜੁਲੇ ਅਪ੍ਰੋਚ ਵਰਤਦੇ ਹਨ: ਜ਼ਿਆਦਾਤਰ ਗਾਹਕ ਸਾਂਝੇ ਢਾਂਚੇ 'ਤੇ ਰਹਿੰਦੇ ਹਨ, ਜਦਕਿ ਵੱਡੇ ਜਾਂ ਨਿਯੰਤਰਤ ਟੇਨੈਂਟਾਂ ਨੂੰ ਨਿਰਧਾਰਤ ਡੇਟਾਬੇਸ ਜਾਂ ਨਿਰਧਾਰਤ ਕਮਪਿਊਟ ਮਿਲਦਾ ਹੈ। ਹਾਈਬ੍ਰਿਡ ਅਕਸਰ ਵਰਤੋਂਯੋਗ ਅੰਤ-ਸਟੇਟ ਹੁੰਦਾ ਹੈ, ਪਰ ਇਸ ਲਈ ਸਪੱਸ਼ਟ ਨਿਯਮ ਲੋੜਦੇ ਹਨ: ਕੌਣ ਯੋਗ ਹੈ, ਕੀ ਲਾਗਤ ਹੈ, ਅਤੇ ਅਪਗ੍ਰੇਡ ਕਿਵੇਂ ਰੋਲ ਆਊਟ ਹੋਣਗੇ।

ਜੇ ਤੁਸੀਂ ਹਰ ਪੈਟਰਨ ਦੇ ਅੰਦਰ ਅਲੱਗਤਾ ਤਕਨੀਕਾਂ ਦੀ ਗਹਿਰਾਈ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਹੋਰ ਲੇਖ ਵੇਖੋ।

ਡੇਟਾ ਅਲੱਗਤਾ ਪੈਟਰਨ (DB, ਸਕੀਮਾ, ਪਿੰਗਤ)

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

ਰੋ-ਲੈਵਲ ਅਲੱਗਤਾ (ਸਾਂਝੇ ਟੇਬਲ + tenant_id)

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

ਜੋਖਮ ਵੀ ਸਿੱਧਾ ਹੈ: ਜੇ ਕਿਸੇ ਵੀ ਕਵੇਰੀ ਨੇ tenant_id ਨਾਲ ਫਿਲਟਰ ਕਰਨਾ ਭੁੱਲ ਗਿਆ, ਤਾਂ ਡੇਟਾ ਲੀਕ ਹੋ ਸਕਦਾ ਹੈ। ਇਨ੍ਹਾਂ ਦਾ ਨਿਵਾਰਣ ਕਰਨ ਲਈ:

• ਸਾਂਝੇ ਡੇਟਾ-ਐਕਸੈਸ ਲੇਅਰ ਵਿੱਚ ਟੇਨੈਂਟ ਫਿਲਟਰ ਲਾਜ਼ਮੀ ਬਣਾਓ (ਤਾਂ ਕਿ ਡਿਵੈਲਪਰ ਹੱਥੋਂ ਫਿਲਟਰ ਨਾ ਲਿਖਣ),
• ਜਿੱਥੇ ਉਪਲਬਧ ਹੋਵੇ ਓਥੇ ਡੇਟਾਬੇਸ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਜਿਵੇਂ row-level security (RLS) ਵਰਤੋ,
• ਆਟੋਮੇਟਿਕ ਟੈਸਟ ਜੋ ਜਾਣਬੂਝ ਕੇ ਕ੍ਰਾਸ-ਟੇਨੈਂਟ ਐਕਸੈਸ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ,
• ਆਮ ਐਕਸੈਸ ਪਾਥ ਲਈ ਇੰਡੈਕਸਿੰਗ (ਅਕਸਰ (tenant_id, created_at) ਜਾਂ (tenant_id, id)) ਤਾਂ ਕਿ ਟੇਨੈਂਟ-ਸਕੋਪਡ ਕਵੇਰੀਜ਼ ਤੇਜ਼ ਰਹਿਣ।

ਸਕੀਮਾ-ਪਰ-ਟੇਨੈਂਟ (ਉਹੀ ਡੇਟਾਬੇਸ, ਵੱਖਰੇ ਸਕੀਮਾ)

ਹਰ ਟੇਨੈਂਟ ਨੂੰ ਆਪਣਾ ਸਕੀਮਾ ਮਿਲਦਾ ਹੈ (ਿਜਾਂ tenant_123.users, tenant_456.users)। ਇਹ ਰੋ-ਲੇਵਲ ਸਾਂਝੇ ਹੋਣ ਨਾਲੋਂ ਵਧੀਕ ਅਲੱਗਤਾ ਦਿੰਦਾ ਹੈ ਅਤੇ ਟੇਨੈਂਟ ਐਕਸਪੋਰਟ ਜਾਂ ਟੇਨੈਂਟ-ਵਿਸ਼ੇਸ਼ ਟਿ੍ਯੂਨਿੰਗ ਆਸਾਨ ਕਰ ਸਕਦਾ ਹੈ।

ਟਰੇਡ-ਆਫ਼ ਓਪਰੇਸ਼ਨਲ ਓਵਰਹੈੱਡ ਹੈ। ਮਾਈਗ੍ਰੇਸ਼ਨ ਬਹੁਤ ਸਾਰੀਆਂ ਸਕੀਮਾਜ਼ 'ਤੇ ਚੱਲਣੀਆਂ ਪੈਂਦੀਆਂ ਹਨ, ਅਤੇ ਫੇਲਿਯਰਜ਼ ਹੋਰ ਕੰਪਲਿਕੇਟ ਹੋ ਸਕਦੇ ਹਨ: ਤੁਸੀਂ 9,900 ਟੇਨੈਂਟਾਂ ਨੂੰ ਸਫਲਤਾਪੂਰਕ ਮਾਈਗਰੇਟ ਕਰ ਸਕਦੇ ਹੋ ਪਰ 100 'ਤੇ ਫਸ ਸਕਦੇ ਹੋ। ਮਾਨੀਟਰਿੰਗ ਅਤੇ ਟੂਲਿੰਗ ਜ਼ਰੂਰੀ ਹਨ—ਤੁਹਾ਼ਦੀ ਮਾਈਗ੍ਰੇਸ਼ਨ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸਪੱਸ਼ਟ ਰੀਟ੍ਰਾਈ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਮੈਕਾਨਿਜ਼ਮ ਚਾਹੀਦੇ ਹਨ।

ਡੇਟਾਬੇਸ-ਪਰ-ਟੇਨੈਂਟ (ਵੱਖਰੇ ਡੇਟਾਬੇਸ)

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

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

ਜਦੋਂ ਟੇਨੈਂਟ ਵੱਧਦਾ ਹੈ ਤਾਂ ਸ਼ਾਰਡਿੰਗ ਅਤੇ ਪਲੇਸਮੈਂਟ ਰਣਨੀਤੀਆਂ

ਅਸਲ ਸਿਸਟਮ ਆਮ ਤੌਰ 'ਤੇ ਇਨ੍ਹਾਂ ਪੈਟਰਨਾਂ ਨੂੰ ਮਿਲਾ ਕੇ ਵਰਤਦੇ ਹਨ। ਇੱਕ ਆਮ ਰਾਹ ਇਹ ਹੈ ਕਿ ਸ਼ੁਰੂਆਤ ਰੋ-ਲੈਵਲ ਅਲੱਗਤਾ ਨਾਲ ਹੁੰਦੀ ਹੈ, ਫਿਰ ਵੱਡੇ ਟੇਨੈਂਟਾਂ ਨੂੰ ਸਕੀਮਾ ਜਾਂ ਡੇਟਾਬੇਸ ਵਿੱਚ "ਗ੍ਰੈਜੂਏਟ" ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

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

ਪਹਿਚਾਨ, ਐਕਸੈਸ, ਅਤੇ ਟੇਨੈਂਟ ਸੰਦਰਭ

ਬਹੁ-ਕਿਰਾਏਦਾਰੀ ਅਸਲ ਵਿੱਚ ਹੈਰਾਨ ਕਰਨ ਵਾਲੇ ਆਮ ਤਰੀਕਿਆਂ ਨਾਲ ਫੇਲ ਹੁੰਦੀ ਹੈ: ਇੱਕ ਗੁੱਮ ਹੋਇਆ ਫਿਲਟਰ, ਇਕ ਕੈਸ਼ ਕੀ ਜੋ ਟੇਨੈਂਟਾਂ ਵਿਚਕਾਰ ਸਾਂਝੀ ਹੋ ਗਈ, ਜਾਂ ਇੱਕ ਐਡਮਿਨ ਫੀਚਰ ਜੋ ਬੇ-ਧਿਆਨ ਹੋ ਕੇ ਪੁਛਦਾ ਹੈ ਕਿ ਕਿਸ ਲਈ ਰਿਕਵੈਸਟ ਹੈ। ਹੱਲ ਕੋਈ ਇਕ ਵੱਡੀ ਸੁਰੱਖਿਆ ਵਿਸ਼ੇਸ਼ਤਾ ਨਹੀਂ—ਇਹ ਪਹਿਲੇ ਬਾਈਟ ਤੋਂ ਆਖਰੀ ਡੇਟਾਬੇਸ ਕਵੇਰੀ ਤੱਕ ਇੱਕ ਸਥਿਰ ਟੇਨੈਂਟ ਸੰਦਰਭ ਹੈ।

ਟੇਨੈਂਟ ਪਛਾਣ (ਤੁਸੀਂ "ਕੌਣ" ਹੋ ਇਹ ਕਿਵੇਂ ਜਾਣਦੇ ਹੋ)

ਜ਼ਿਆਦਾਤਰ SaaS ਉਤਪਾਦ ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਪਹਚਾਣ ਤੇ ਠਹਿਰਦੇ ਹਨ ਅਤੇ ਹੋਰ ਸਿਗਨਲ ਸਹੂਲਤ ਵਜੋਂ ਮੰਨਦੇ ਹਨ:

• ਸਬਡੋਮੇਨ: acme.yourapp.com ਉਪਭੋਗਤਿਆਂ ਲਈ ਆਸਾਨ ਹੈ ਅਤੇ ਟੇਨੈਂਟ-ਬ੍ਰਾਂਡਡ ਅਨੁਭਵਾਂ ਨਾਲ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ।
• ਹੈਡਰ: API ਕਲਾਇੰਟ ਅਤੇ ਅੰਦਰੂਨੀ ਸਰਵਿਸز ਲਈ ਲਾਭਦਾਇਕ (ਪਰ ਪ੍ਰਮਾਣਿਕ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ)।
• ਟੋਕਨ ਕਲੇਮ: ਇੱਕ ਸਾਈਨ ਕੀਤਾ JWT (ਜਾਂ ਸੈਸ਼ਨ) tenant_id ਸ਼ਾਮਿਲ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਤਬਦੀਲੀ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ।

ਇੱਕ ਸਿੰਗਲ ਤਥ੍ਯ ਸ੍ਰੋਤ ਚੁਣੋ ਅਤੇ ਹਰ ਥਾਂ ਉਸ ਨੂੰ ਲੌਗ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਕਈ ਸਿਗਨਲ (ਸਬਡੋਮੇਨ + ਟੋਕਨ) ਸਹਾਇਕ ਹੋ, ਤਾਂ ਪ੍ਰਾਥਮਿਕਤਾ ਨਿਰਧਾਰਤ ਕਰੋ ਅਤੇ ਅਸਪਸ਼ਟ ਬੇਨਤੀਆਂ ਨੂੰ ਢੱਕ ਦਿਓ।

ਰਿਕਵੈਸਟ ਸਕੋਪਿੰਗ (ਕਿਵੇਂ ਹਰ ਕਵੇਰੀ ਟੇਨੈਂਟ ਵਿੱਚ ਹੀ ਰਹਿੰਦੀ ਹੈ)

ਅਚਛਾ ਨਿਯਮ: ਜਦੋਂ ਤੁਸੀਂ tenant_id ਹੱਲ ਕਰ ਲੈਂਦੇ ਹੋ, ਤਾਂ ਨੀਚਲੇ ਸਾਰੇ ਹਿੱਸੇ ਨੂੰ ਇਹ ਇੱਕ ਹੀ ਸਥਾਨ (ਰਿਕਵੈਸਟ ਕ.context) ਤੋਂ ਪੜ੍ਹਨਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਮੁੜ ਤੋਂ ਨਿਕਾਲਿਆ ਜਾਵੇ।

ਆਮ ਗਾਰਡਰੇਲਾਂ ਵਿੱਚ ਸ਼ਾਮਿਲ ਹਨ:

• ਮਿਡਲਵੇਅਰ ਜੋ tenant_id ਨੂੰ ਰਿਕਵੈਸਟ ਕ.context ਵਿੱਚ ਜੁੜਦਾ ਹੈ
• ਡੇਟਾ-ਐਕਸੈਸ ਹੈਲਪਰ ਜੋ tenant_id ਨੂੰ ਪੈਰਾਮੀਟਰ ਵਜੋਂ ਲੈਣਾ ਲਾਜ਼ਮੀ ਬਣਾਉਂਦੇ ਹਨ
• ਡੇਟਾਬੇਸ-ਪ੍ਰਵਾਨਗੀ (ਜਿਵੇਂ row-level policies) ਤਾਂ ਕਿ ਗਲਤੀਆਂ fail-closed ਹੋ ਜਾਣ

handleRequest(req):
  tenantId = resolveTenant(req)   // subdomain/header/token
  req.context.tenantId = tenantId
  return next(req)

ਅਥੋਰਾਈਜ਼ੇਸ਼ਨ ਬੁਨਿਆਦੀ ਗੱਲਾਂ (ਟੇਨੈਂਟ ਦੇ ਅੰਦਰ ਭੂਮਿਕਾਵਾਂ)

ਪ੍ਰਮਾਣਿਕਤਾ (ਉਪਭੋਗਤਾ ਕੌਣ ਹੈ) ਨੂੰ ਅਧਿਕਾਰ (ਉਹ ਕੀ ਕਰ ਸਕਦੇ ਹਨ) ਤੋਂ ਵੱਖ ਕਰੋ।

ਆਮ SaaS ਭੂਮਿਕਾਵਾਂ Owner / Admin / Member / Read-only ਹੁੰਦੀਆਂ ਹਨ, ਪਰ ਕੁੰਜੀ ਏਹ ਹੈ ਕਿ ਸਕੋਪ: ਇੱਕ ਉਪਭੋਗਤਾ Tenant A ਵਿੱਚ Admin ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ Tenant B ਵਿੱਚ Member। ਅਧਿਕਾਰਾਂ ਨੂੰ ਪ੍ਰਤੀ-ਟੇਨੈਂਟ ਸਟੋਰ ਕਰੋ, ਗਲੋਬਲ ਨਹੀਂ।

ਕ੍ਰਾਸ-ਟੇਨੈਂਟ ਲੀਕ ਰੋਕਣਾ (ਟੈਸਟ ਅਤੇ ਗਾਰਡਰੇਲ)

ਕ੍ਰਾਸ-ਟੇਨੈਂਟ ਐਕਸੈਸ ਨੂੰ ਇੱਕ ਟੌਪ-ਟੀਅਰ ਇਨਸਿਡੈਂਟ ਵਜੋਂ ਲਓ ਅਤੇ ਇਸਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤਰੀਕੇ ਨਾਲ ਰੋਕੋ:

• ਆਟੋਮੇਟਿਕ ਟੈਸਟ ਜੋ Tenant A ਦੇ ਤੌਰ 'ਤੇ Authenticate ਹੋ ਕੇ Tenant B ਦਾ ਡੇਟਾ ਪੜ੍ਹਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ
• ਗੁੰਮ ਟੇਨੈਂਟ ਫਿਲਟਰ ਬੱਗਾਂ ਨੂੰ ਸ਼ਿਪ ਕਰਨ ਨੂੰ ਔਖਾ ਬਣਾਉ (ਲਿੰਟਰ, ਕਵੇਰੀ ਬਿਲਡਰ, ਲਾਜ਼ਮੀ ਟੇਨੈਂਟ ਪੈਰਾਮੀਟਰ)
• ਸ਼ੱਕੀ ਪੈਟਰਨਾਂ (ਜਿਵੇਂ ਟੋਕਨ ਅਤੇ ਸਬਡੋਮੇਨ ਵਿਚਕਾਰ ਟੇਨੈਂਟ ਮਿਸਮੈਚ) 'ਤੇ ਲੌਗ ਅਤੇ ਅਲਰਟ ਬਣਾਓ

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

ਡੇਟਾਬੇਸ ਤੋਂ ਆਗੇ ਅਲੱਗਤਾ

ਡੇਟਾਬੇਸ ਅਲੱਗਤਾ ਸਿਰਫ਼ ਅੱਧੀ ਕਹਾਣੀ ਹੈ। ਬਹੁਤ ਸਾਰੇ ਅਸਲ ਬਹੁ-ਕਿਰਾਏਦਾਰ ਘਟਨਾ ਉਸ ਐਪ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਦੇ ਸਾਂਝੇ ਪਲੰਬਿੰਗ: ਕੈਸ਼, ਕਿਊ, ਅਤੇ ਸਟੋਰੇਜ ਵਿੱਚ ਹੁੰਦੇ ਹਨ। ਇਹ ਲੇਅਰ ਤੇਜ਼ ਅਤੇ ਸਹੂਲਤ-ਭਰਪੂਰ ਹਨ ਅਤੇ ਅਕਸਰ ਅਜਿਹੇ ਢੰਗ ਨਾਲ ਗਲਤੀ ਨਾਲ ਗਲੋਬਲ ਬਣ ਜਾਂਦੇ ਹਨ।

ਸਾਂਝੇ ਕੈਸ਼: ਕੀ ਕਿੱਥੇ ਟੇਨੈਂਟ-ਸਪੇਸ਼ਿਫਿਕ ਕੀ ਪ੍ਰੀਫਿਕਸ ਕਰਨਾ ਅਤੇ ਡੇਟਾ ਲੀਕ ਰੋਕਣਾ

ਜੇ ਕਈ ਟੇਨੈਂਟ Redis ਜਾਂ Memcached ਸਾਂਝਾ ਕਰਦੇ ਹਨ, ਮੁੱਖ ਨਿਯਮ ਸਧਾਰਨ ਹੈ: ਕਦੇ ਵੀ ਟੇਨੈਂਟ-ਅਗਨੋਸਟਿਕ ਕੀ ਰੱਖੋ ਨਾ।

ਇੱਕ ਵਿਹਾਰਿਕ ਪੈਟਰਨ ਹਰ ਕੀ ਨੂੰ ਇੱਕ ਸਥਿਰ ਟੇਨੈਂਟ ਪਛਾਣ ਨਾਲ ਪ੍ਰੀਫਿਕਸ ਕਰਨਾ ਹੈ (ਨਾਂ ਕਿ ਈਮੇਲ ਡੋਮੇਨ, ਨਾਂ ਹੀ ਪ੍ਰਦਰਸ਼ਨ ਨਾਂ)। ਉਦਾਹਰਨ ਲਈ: t:{tenant_id}:user:{user_id}। ਇਸ ਨਾਲ ਦੋ ਕੰਮ ਹੋਂਦੇ ਹਨ:

• ਉਹਨਾਂ ਸਥਿਤੀਆਂ ਤੋਂ ਟੱਲਣ ਤੋਂ ਰੋਕਦਾ ਹੈ ਜਿੱਥੇ ਦੋ ਟੇਨੈਂਟਾਂ ਦੇ ਇੱਕੋ-ਜੇਹੇ ਆਂਤਰਿਕ ID ਹੋ ਸਕਦੇ ਹਨ
• ਸਪੋਰਟ ਇਨਸਿਡੈਂਟ ਜਾਂ ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੌਰਾਨ ਬਲਕ ਇਨਵੈਲਿਡੇਸ਼ਨ ਸੰਭਵ ਬਣਾਂਦਾ ਹੈ (ਪ੍ਰੀਫਿਕਸ ਦੁਆਰਾ ਹਟਾਉ)

ਇਸ ਤੋਂ ਇਲਾਵਾ ਇਹ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਕੀ ਗਲੋਬਲ ਤੌਰ 'ਤੇ ਸਾਂਝਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ਪਬਲਿਕ ਫੀਚਰ ਫਲੈਗ, ਸਟੈਟਿਕ ਮੈਟਾ ਡੇਟਾ) ਅਤੇ ਇਸਨੂੰ ਦਸਤਾਵੇਜ਼ ਕਰੋ—ਅਕਸਮਾਤ ਗਲੋਬਲਜ਼ ਅਕਸਰ ਕ੍ਰਾਸ-ਟੇਨੈਂਟ ਐਕਸਪੋਜ਼ਰ ਦਾ ਸਰੋਤ ਹੁੰਦੇ ਹਨ।

ਟੇਨੈਂਟ-ਅਗਾਹ ਰੇਟ-ਲਿਮਿਟ ਅਤੇ ਕੋਟਾ

ਭਾਵੇਂ ਡੇਟਾ ਅਲੱਗ ਹੋਵੇ, ਟੇਨੈਂਟ ਫਿਰ ਵੀ ਸਾਂਝੇ ਕਮਪਿਊਟ ਦੁਆਰਾ ਹੋਰਾਂ 'ਤੇ ਪ੍ਰਭਾਵ ਸਕਦਾ ਹੈ। ਕਿਨਾਰੇ ਤੇ ਟੇਨੈਂਟ-ਅਗਾਹ ਲਿਮਿਟ ਲਗਾਓ:

• API ਰੇਟ-ਲਿਮਿਟ ਪ੍ਰਤੀ ਟੇਨੈਂਟ (ਅਤੇ ਅਕਸਰ ਪ੍ਰਤੀ ਉਪਭੋਗਤਾ)\n- ਮਹਿੰਗੇ ਓਪਰੇਸ਼ਨ (ਐਕਸਪੋਰਟ, ਰਿਪੋਰਟ ਸੈਟ, AI ਕਾਲ) ਲਈ ਕੋਟਾ

ਸੀਮਾ ਨੂੰ ਦਿੱਖਵਾਈ ਬਣਾਓ (ਹੈਡਰ, UI ਨੋਟਿਸ) ਤਾਂ ਕਿ ਗਾਹਕ ਸਮਝ ਸਕਣ ਕਿ throttling ਨੀਤੀ ਹੈ, ਤਕਨੀਕੀ ਖਾਮੀ ਨਹੀਂ।

ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ: ਕਤਾਰਾਂ ਨੂੰ ਟੇਨੈਂਟ ਦੁਆਰਾ ਵੰਡੋ

ਇੱਕ ਇੱਕੋ-ਕਿਊ ਵੱਲੋਂ ਇੱਕ ਵਿਆਸਤ ਟੇਨੈਂਟ ਵਰਕਰ ਸਮੇਂ 'ਤੇ ਹਵਾਲਾ ਕਰ ਸਕਦਾ ਹੈ।

ਆਮ ਫਿਕਸ:

• ਟੀਅਰ/ਪਲੇਨ ਦੇ ਅਨੁਸਾਰ ਵੱਖ-ਵੱਖ ਕਤਾਰਾਂ (free, pro, enterprise)
• ਟੇਨੈਂਟ ਬਕਟ ਦੁਆਰਾ Partition ਕੀਤੇ ਗਏ ਕਤਾਰ (tenant_id ਨੂੰ N ਕਤਾਰਾਂ ਵਿੱਚ ਹੈਸ਼ ਕਰੋ)
• ਟੇਨੈਂਟ-ਅਗਾਹ ਸ਼ੈਡਿਊਲਿੰਗ ਤਾਂ ਜੋ ਹਰ ਟੇਨੈਂਟ ਨੂੰ ਨਿਆਂਯੁਕਤ ਹਿੱਸਾ ਮਿਲੇ

ਹਮੇਸ਼ਾ ਜੌਬ ਪੇਲੋਡ ਅਤੇ ਲੌਗ ਵਿੱਚ ਟੇਨੈਂਟ ਸੰਦਰਭ ਪ੍ਰੋਪੈਗੇਟ ਕਰੋ ਤਾਂ ਕਿ ਗਲਤ-ਟੇਨੈਂਟ ਸਾਈਡ-ਇਫੈਕਟ ਤੋਂ ਬਚਾ ਜਾ ਸਕੇ।

ਫ਼ਾਇਲ/ਆਬਜੈਕਟ ਸਟੋਰੇਜ: ਵੱਖਰੇ ਪਾਥ, ਨੀਤੀਆਂ, ਅਤੇ ਕੁੰਜੀਆਂ

S3/GCS-ਜੈਹੇ ਸਟੋਰੇਜ ਲਈ ਅਲੱਗਤਾ ਆਮ ਤੌਰ 'ਤੇ ਪਾਥ ਅਤੇ ਨੀਤੀ-ਅਧਾਰਿਤ ਹੁੰਦੀ ਹੈ:

• ਸਖ਼ਤ ਅਲੱਗਤਾ ਲਈ ਹਰ ਟੇਨੈਂਟ ਲਈ ਬੱਕੇਟ
• ਅਸਾਨੀ ਲਈ ਟੇਨੈਂਟ ਪ੍ਰੀਫਿਕਸ ਦੇ ਨਾਲ ਸਾਂਝਾ ਬੱਕੇਟ (ਇਸ ਨੂੰ ਧਿਆਨ ਨਾਲ IAM ਅਤੇ ਸਾਈਨ ਕੀਤੇ URLs ਦੀ ਲੋੜ)

ਜੋ ਵੀ ਤੁਸੀਂ ਚੁਣੋ, ਇਹ ਨਿਸ਼ਚਿਤ ਕਰੋ ਕਿ ਉੱਪਲੋਡ/ਡਾਊਨਲੋਡ ਹਰ ਰਿਕਵੈਸਟ 'ਤੇ ਟੇਨੈਂਟ ਮਾਲਕੀ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ, ਸਿਰਫ UI 'ਤੇ ਨਹੀਂ।

ਨੋਇਜ਼ੀ-ਨੇਬਰਾਂ ਅਤੇ ਨਿਆਂਯੁਕਤ ਸਰੋਤ ਉਪਯੋਗਤਾ ਨੂੰ ਸੰਭਾਲਣਾ

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

"ਨੋਇਜ਼ੀ ਨੇਬਰ" ਕਿਵੇਂ ਦਿਖਦਾ ਹੈ

ਕਲਪਨਾ ਕਰੋ ਕਿ ਇੱਕ ਰਿਪੋਰਟਿੰਗ ਫੀਚਰ ਇੱਕ ਸਾਲ ਦਾ ਡੇਟਾ CSV ਵਿੱਚ ਨਿਕਾਸ ਕਰ ਰਿਹਾ ਹੈ। ਟੇਨੈਂਟ A 9:00 ਵਜੇ 20 ਐਕਸਪੋਰਟ ਸ਼ਡਿਊਲ ਕਰਦਾ ਹੈ। ਉਹ ਐਕਸਪੋਰਟ CPU ਅਤੇ ਡੇਟਾਬੇਸ I/O ਭਰ ਦਿੰਦੇ ਹਨ, ਤਾਂ ਜੋ ਟੇਨੈਂਟ B ਦੇ ਆਮ ਐਪ ਸਕ੍ਰੀਨ ਟਾਈਮਆਉਟ ਹੋਣ ਲੱਗ ਜਾਂਦੇ ਹਨ—ਭਾਵੇਂ B ਕੁਝ ਅਸਧਾਰਣ ਨਹੀਂ ਕਰ ਰਿਹਾ।

ਸਰੋਤ ਨਿਯੰਤਰਣ: ਸੀਮਾਵਾਂ, ਕੋਟਾ, ਅਤੇ ਵਰਕਲੋਡ ਸ਼ੇਪਿੰਗ

ਇਸ ਨੂੰ ਰੋਕਣਾ ਖੁੱਲ੍ਹੇ ਨਿਯੰਤ੍ਰਿਤ ਸਰਹੱਦਾਂ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ:

• ਰੇਟ ਲਿਮਿਟਸ (ਪ੍ਰਤੀ ਸਕਿੰਟ ਬੇਨਤੀਆਂ) ਪ੍ਰਤੀ ਟੇਨੈਂਟ ਅਤੇ ਪ੍ਰਤੀ ਐਂਡਪੌਇੰਟ, ਤਾਂ ਕਿ ਮਹਿੰਗੇ API spam ਨਾ ਹੋ ਸਕਣ।
• ਕੋਟਾ (ਦੈਨੀ/ਮਾਸਿਕ ਕੁੱਲ) ਐਕਸਪੋਰਟ, ਈਮੇਲ, AI ਕਾਲਾਂ ਜਾਂ ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬਾਂ ਵਰਗੀਆਂ ਚੀਜ਼ਾਂ ਲਈ।
• ਵਰਕਲੋਡ ਸ਼ੇਪਿੰਗ: ਭਾਰੀ ਕਾਰਜਾਂ (ਐਕਸਪੋਰਟ, ਇੰਪੋਰਟ, ਰੀ-ਇਂਡੇਕਸ) ਨੂੰ ਪ੍ਰਤੀ-ਟੇਨੈਂਟ concurrency ਕੈਪ ਅਤੇ ਪ੍ਰਾਥਮਿਕਤਾ ਨਿਯਮਾਂ ਵਾਲੀਆਂ ਕਤਾਰਾਂ ਵਿੱਚ ਰੱਖੋ।

ਇੱਕ ਵਿਹਾਰਿਕ ਪੈਟਰਨ ਇੰਟਰਐਕਟਿਵ ਟਰੈਫਿਕ ਨੂੰ ਬੈਚ ਕੰਮ ਤੋਂ ਅਲੱਗ ਰੱਖਣਾ ਹੈ: ਉਪਭੋਗਤਾ-ਮੁੱਖੀ ਰਿਕਵੈਸਟ ਤੇਜ਼ ਲੇਨ 'ਤੇ ਰੱਖੋ, ਅਤੇ ਹੋਰ ਸਭ ਕੁਝ ਨਿਯੰਤਰਿਤ ਕਤਾਰਾਂ ਵਿੱਚ ਧੱਕੋ।

ਪ੍ਰਤੀ-ਟੇਨੈਂਟ ਸਰਕਿਟ ਬ੍ਰੇਕਰ ਅਤੇ ਬਲਕਹੈਡ

ਜਦੋਂ ਇੱਕ ਟੇਨੈਂਟ ਇੱਕ ਸੀਮਾ ਅਗੇ ਕੀਤੇ ਤਾਂ ਸੁਰੱਖਿਆ ਵਾਲੇ ਵੈਨਾਂ ਜੋੜੋ:

• ਸਰਕਿਟ ਬ੍ਰੇਕਰ: ਜਦੋਂ ਗਲਤੀਆਂ ਦਰ, ਲੈਟੈਂਸੀ, ਜਾਂ ਕਤਾਰ ਡੈਪਥ ਟੇਨੈਂਟ ਲਈ ਲਿਮਿਟਾਂ ਤੋਂ ਉਪਰ ਚਲਣ, ਮੁੜ-ਅਸਵੀਕਾਰ ਜਾਂ ਮੁਲਤਵੀ ਕਰੋ।
• ਬਲਕਹੈਡ: ਸਾਂਝੇ ਪੂਲਾਂ (DB ਕਨੈਕਸ਼ਨ, ਵਰਕਰ ਥ੍ਰੈਡ, ਕੈਸ਼) ਨੂੰ ਅਲੱਗ ਕਰਕੇ ਰੱਖੋ ਤਾਂ ਜੋ ਇੱਕ ਟੇਨੈਂਟ ਗਲੋਬਲ ਸਮਰੱਥਾ ਖਤਮ ਨਾ ਕਰ ਸਕੇ।

ਢੰਗ ਨਾਲ ਕੀਤਿਆਂ, ਟੇਨੈਂਟ A ਆਪਣੀ ਐਕਸਪੋਰਟ ਸਪੀਡ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦਾ ਹੈ ਬਿਨਾਂ ਟੇਨੈਂਟ B ਨੂੰ ਡਾਂਨ ਕਦੇ।

ਕਿਸ ਵੇਲੇ ਕਿਸੇ ਟੇਨੈਂਟ ਨੂੰ ਨਿਰਧਾਰਤ ਸਮਰੱਥਾ 'ਤੇ ਮੂਵ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ

ਜਦੋਂ ਕੋਈ ਟੇਨੈਂਟ ਲਗਾਤਾਰ ਸਾਂਝੇ ਅਨੁਮਾਨਾਂ ਤੋਂ ਵੱਧ ਹੁੰਦਾ ਹੈ: ਲਗਾਤਾਰ ਉੱਚ throughput, ਅਣਪਛਾਤੀ spikes ਜੋ ਕਾਰੋਬਾਰੀ-ਮਹੱਤਵਪੂਰਨ ਘਟਨਾਵਾਂ ਨਾਲ ਟਾਈ ਕੀਤਾ ਹੁੰਦਾ ਹੈ, ਕਠੋਰ ਕੰਪਲਾਇੰਸ ਲੋੜਾਂ, ਜਾਂ ਜਦੋਂ ਉਨ੍ਹਾਂ ਦਾ ਵਰਕਲੋਡ ਕਸਟਮ ਟਿਊਨਿੰਗ ਮੰਗਦਾ ਹੈ। ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ: ਜੇ ਹੋਰ ਟੇਨੈਂਟਾਂ ਦੀ ਰੱਖਿਆ ਲਈ ਇੱਕ ਗ੍ਰਾਹਕ ਨੂੰ ਸਥਾਈ ਤੌਰ 'ਤੇ throttle ਕਰਨਾ ਪੈਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਸਮਾਂ ਹੈ ਕਿ ਉਸਨੂੰ ਨਿਰਧਾਰਤ ਸਮਰੱਥਾ (ਜਾਂ ਉੱਚ ਟੀਅਰ) 'ਤੇ ਲਿਜਾਇਆ ਜਾਵੇ, ਨਾ ਕਿ ਹਮੇਸ਼ਾ ਦੀ ਫਾਇਰਫਾਈਟਿੰਗ।

ਬਹੁ-ਕਿਰਾਏਦਾਰ SaaS ਵਿੱਚ ਕੰਮ ਕਰਨ ਵਾਲੇ ਸਕੇਲਿੰਗ ਪੈਟਰਨ

ਬਹੁ-ਕਿਰਾਏਦਾਰ ਸਕੇਲਿੰਗ "ਵੱਧ ਸਰਵਰ" ਬਾਰੇ ਘੱਟ ਅਤੇ ਇੱਕ ਟੇਨੈਂਟ ਦੀ ਵੱਧਣ ਨੂੰ ਸਭ ਨੂੰ ਹੈਰਾਨ ਨਾ ਕਰਨ ਵਾਲਾ ਬਣਾਉਣ ਬਾਰੇ ਜ਼ਿਆਦਾ ਹੈ। ਸਭ ਤੋਂ ਵਧੀਆ ਪੈਟਰਨ ਸਕੇਲ ਨੂੰ ਪੂਰਵਾਨੁਮਾਨ, ਮਾਪਯੋਗ ਅਤੇ ਵਾਪਸੀਯੋਗ ਬਣਾਉਂਦੇ ਹਨ।

ਸਟੇਟਲੈੱਸ ਸਰਵਿਸਜ਼ ਲਈ ਹੋਰਾਇਜ਼ੌਂਟਲ ਸਕੇਲਿੰਗ

ਆਪਣੇ ਵੈੱਬ/API ਟੀਅਰ ਨੂੰ ਸਟੇਟਲੈੱਸ ਬਣਾਉ: ਸੈਸ਼ਨ ਨੂੰ ਸਾਂਝੀ ਕੈਸ਼ ਵਿੱਚ ਰੱਖੋ (ਜਾਂ ਟੋਕਨ-ਅਧਾਰਿਤ ਪ੍ਰਮਾਣਿਕਤਾ ਵਰਤੋ), ਅੱਪਲੋਡਸ ਨੂੰ ਓਬਜੈਕਟ ਸਟੋਰੇਜ ਵਿੱਚ ਰੱਖੋ, ਅਤੇ ਲੰਬੇ-ਚੱਲਣ ਵਾਲੇ ਕੰਮਾਂ ਨੂੰ ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬਜ਼ 'ਤੇ ਧੱਕੋ। ਜਦੋਂ ਰਿਕਵੈਸਟ ਲੋਕਲ ਮੈਮੋਰੀ ਜਾਂ ਡਿਸਕ 'ਤੇ ਨਿਰਭਰ ਨਾ ਹੋਣ, ਤਾਂ ਤੁਸੀਂ ਲੋਡ ਬੈਲੈਂਸਰ ਪਿੱਛੇ ਇਨਸਟੈਂਸ ਜੋੜਕੇ ਤੇਜ਼ੀ ਨਾਲ ਸਕੇਲ ਕਰ ਸਕਦੇ ਹੋ।

ਇੱਕ ਵਿਕਾਰਕ ਸੁਝਾਅ: ਕਿਨਾਰੇ 'ਤੇ ਟੇਨੈਂਟ ਸੰਦਰਭ ਰੱਖੋ (ਸਬਡੋਮੇਨ ਜਾਂ ਹੈਡਰ ਤੋਂ ਨਿਕਾਲਿਆ) ਅਤੇ ਇਸਨੂੰ ਹਰ ਰਿਕਵੈਸਟ ਹੈਂਡਲਰ ਤੱਕ ਪਾਸ ਕਰੋ। ਸਟੇਟਲੈੱਸ ਦਾ ਮਤਲਬ ਟੇਨੈਂਟ-ਅਗਿਆਹ ਨਹੀਂ—ਇਹ ਉਹ ਹੈ ਕਿ ਸਰਵਰ ਸਟਿੱਕੀ (sticky) ਨਾ ਹੋਣ।

ਪ੍ਰਤੀ-ਟੇਨੈਂਟ ਹੌਟਸਪੌਟ: ਪਛਾਣ ਅਤੇ ਸੁਥਰਾ ਕਰਨਾ

ਜ਼ਿਆਦਾਤਰ ਸਕੇਲਿੰਗ ਸਮੱਸਿਆਵਾਂ "ਇਕ ਟੇਨੈਂਟ ਵੱਖਰਾ ਹੈ" ਧਰਾਂ ਹੁੰਦੀਆਂ ਹਨ। ਹੌਟਸਪੌਟਾਂ ਲਈ ਨਜ਼ਰ ਰੱਖੋ ਜਿਵੇਂ:

• ਇਕ ਹੀ ਟੇਨੈਂਟ ਜੋ ਬਹੁਤ ਵੱਧ ਟ੍ਰੈਫਿਕ ਜਨਰੇਟ ਕਰ ਰਿਹਾ ਹੈ
• ਕੁਝ ਟੇਨੈਂਟ ਜਿਨ੍ਹਾਂ ਦੇ ਡੇਟਾਸੈਟ ਬਹੁਤ ਵੱਡੇ ਹਨ
• ਬੈਚੀ ਵਰਤੋਂ (ਮਹੀਨੇ ਦੇ ਅੰਤ ਦੀਆਂ ਰਿਪੋਰਟਾਂ, ਰਾਤੀ ਦੀਆਂ ਇੰਪੋਰਟ)

ਸਮੋਥਨਿੰਗ ਤਰਕੀਬਾਂ ਵਿੱਚ ਪ੍ਰਤੀ-ਟੇਨੈਂਟ ਰੇਟ ਲਿਮਿਟ, ਕਤਾਰ-ਅਧਾਰਤ ਇਨਜੈਸ਼ਨ, ਟੇਨੈਂਟ-ਵਿਸ਼ੇਸ਼ ਰੀਡ ਪਾਥ ਲਈ ਕੈਸ਼ਿੰਗ, ਅਤੇ ਭਾਰੀ ਟੇਨੈਂਟਾਂ ਨੂੰ ਵੱਖਰੇ ਵਰਕਰ ਪੂਲਾਂ ਵਿੱਚ ਸ਼ਾਰਡ ਕਰਨਾ ਸ਼ਾਮਿਲ ਹੈ।

ਪੜ੍ਹਨ ਵਾਲੇ ਰੇਪਲਿਕਾ, ਪਾਰਟੀਸ਼ਨਿੰਗ, ਅਤੇ ਐਸਿੰਗਕ ਵਰਕਲੋਡ

ਰੀਡ-ਭਾਰ ਵਾਲੇ ਵਰਕਲੋਡ (ਡੈਸ਼ਬੋਰਡ, ਖੋਜ, ਐਨਾਲਿਟਿਕਸ) ਲਈ ਰੀਡ ਰੇਪਲਿਕਾ ਵਰਤੋ ਅਤੇ ਲਿਖਾਈਆਂ ਪ੍ਰਾਇਮਰੀ 'ਤੇ ਰੱਖੋ। ਪਾਰਟੀਸ਼ਨਿੰਗ (ਟੇਨੈਂਟ, ਸਮਾਂ, ਜਾਂ ਦੋਹਾਂ ਦੁਆਰਾ) ਇੰਡੈਕਸ ਛੋਟੇ ਅਤੇ ਕਵੇਰੀਜ਼ ਤੇਜ਼ ਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ। ਮਹਿੰਗੇ ਟਾਸਕ—ਐਕਸਪੋਰਟ, ML ਸਕੋਰਿੰਗ, ਵੈੱਬਹੁੱਕਸ—ਲਈ ਐਸਿੰਗਕ ਜੌਬ ਪਸੰਦ ਕਰੋ ਅਤੇ idempotency ਰੱਖੋ ਤਾਂ ਕਿ ਰੀਟ੍ਰਾਈਜ਼ ਲੋਡ ਨੂੰ ਚਾਰ ਗੁਣਾ ਨਾ ਕਰਨ।

ਸਮਰੱਥਾ ਯੋਜਨਾ ਲਈ ਸਿਗਨਲ ਅਤੇ ਸਧਾਰਨ ਸੀਮਾ-ਰেখਾ

ਸਿਗਨਲ ਸਧਾਰਨ ਅਤੇ ਟੇਨੈਂਟ-ਅਗਿਆह ਰੱਖੋ: p95 ਲੈਟੈਂਸੀ, ਐਰਰ ਦੀ ਦਰ, ਕਤਾਰ ਡੈਪਥ, DB CPU, ਅਤੇ ਪ੍ਰਤੀ-ਟੇਨੈਂਟ ਬੇਨਤੀ ਦਰ। ਆਸਾਨ ਸੀਮਾ-ਰেখਾ ਸੈਟ ਕਰੋ (ਜਿਵੇਂ "ਕਤਾਰ ਡੈਪਥ > N 10 ਮਿੰਟ ਲਈ" ਜਾਂ "p95 > X ms") ਜੋ ਆਟੋਸਕੇਲਿੰਗ ਜਾਂ ਅਸਥਾਈ ਟੇਨੈਂਟ ਕੈਪ ਪ੍ਰਰੇਰਣਾ ਕਰੇ—ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਹੋਰ ਟੇਨੈਂਟਾਂ ਨੂੰ ਫੀਲ ਹੋਵੇ।

ਟੇਨੈਂਟ ਦੁਆਰਾ ਨਿਗਰਾਨੀ ਅਤੇ ਓਪਰੇਸ਼ਨ

ਬਹੁ-ਕਿਰਾਏਦਾਰ ਸਿਸਟਮ ਆਮ ਤੌਰ 'ਤੇ ਗਿਆਨਵਾਨੀ ਤਰੀਕੇ ਨਾਲ ਪਹਿਲਾਂ ਗਲਤ ਨਹੀਂ ਹੁੰਦੇ—ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਟੇਨੈਂਟ, ਇੱਕ ਟੀਅਰ, ਜਾਂ ਇੱਕ ਨੋਇਜ਼ੀ ਵਰਕਲੋਡ ਲਈ ਫੇਲ ਹੁੰਦੇ ਹਨ। ਜੇ ਤੁਹਾਡੇ ਲੌਗ ਅਤੇ ਡੈਸ਼ਬੋਰਡ "ਕਿਹੜਾ ਟੇਨੈਂਟ ਪ੍ਰਭਾਵਿਤ ਹੋਇਆ?" ਦਾ ਸਵਾਲ ਸੈਕਿੰਡਾਂ ਵਿੱਚ ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦੇ, ਤਾਂ ਆਨ-ਕਾਲ ਸਮਾਂ ਅਨਡਰਸਪਂਡ ਹੋ ਜਾਂਦਾ ਹੈ।

ਟੇਨੈਂਟ-ਅਗਿਆਹ ਲੌਗ, ਮੈਟ੍ਰਿਕਸ, ਅਤੇ ਟ੍ਰੇਸ

ਟੈਲੀਮੇਟਰੀ 'ਤੇ ਇੱਕ ਸਥਿਰ ਟੇਨੈਂਟ ਸੰਦਰਭ ਰੱਖ ਕੇ ਸ਼ੁਰੂ ਕਰੋ:

• ਲੌਗ: ਹਰ ਰਿਕਵੈਸਟ ਅਤੇ ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ 'ਤੇ tenant_id, request_id, ਅਤੇ ਇੱਕ ਸਥਿਰ actor_id (ਉਪਭੋਗਤਾ/ਸਰਵਿਸ) ਸ਼ਾਮਿਲ ਕਰੋ।
• ਮੈਟ੍ਰਿਕਸ: ਡੀਟਰ-ਬ੍ਰੋਕਨ ਕਾਊਂਟਰ ਅਤੇ ਲੈਟੈਂਸੀ histogram ਟੀਅਰ ਦੁਆਰਾ (ਉਦਾਹਰਨ tier=basic|premium) ਅਤੇ ਉੱਚ-ਸਤਰ ਐਂਡਪੌਇੰਟਾਂ ਦੁਆਰਾ ਜਾਰੀ ਕਰੋ (ਕੱਚੇ URLs ਨਹੀਂ)।
• ਟ੍ਰੇਸ: ਟੇਨੈਂਟ ਸੰਦਰਭ ਨੂੰ trace attribute ਵਜੋਂ ਪ੍ਰੋਪੈਗੇਟ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਕਿਸੇ ਧੀਮੇ ਟਰੇਸ ਨੂੰ ਇੱਕ ਖਾਸ ਟੇਨੈਂਟ ਤੱਕ ਫਿਲਟਰ ਕਰ ਸਕੋ ਅਤੇ ਦੇਖ ਸਕੋ ਕਿ ਸਮਾਂ ਕਿੱਥੇ ਲੱਗ ਰਿਹਾ ਹੈ (DB, ਕੈਸ਼, ਤੀਜੀ-ਪੱਖੀ ਕਾਲਾਂ)।

ਕਾਰਡੀਨਾਲਿਟੀ ਨੂੰ ਨਿਯੰਤਰਣ ਵਿੱਚ ਰੱਖੋ: ਸਾਰੇ ਟੇਨੈਂਟਾਂ ਲਈ ਪ੍ਰਤੀ-ਟੇਨੈਂਟ ਮੈਟ੍ਰਿਕਸ ਮਹਿੰਗੇ ਹੋ ਸਕਦੇ ਹਨ। ਇੱਕ ਆਮ ਸਮਝੌਤਾ ਇਹ ਹੈ ਕਿ ਡਿਫੌਲਟ ਤੌਰ 'ਤੇ ਟੀਅਰ-ਸਤਰ ਮੈਟ੍ਰਿਕਸ ਅਤੇ ਮੰਗ 'ਤੇ ਪ੍ਰਤੀ-ਟੇਨੈਂਟ ਡ੍ਰਿਲ-ਡਾਊਨ (ਉਦਾਹਰਨ, "ਟਾਪ 20 ਟੇਨੈਂਟ ਬਾਇ ਟ੍ਰੈਫਿਕ") ਲਈ ਟਰੇਸ ਸੈਂਪਿੰਗ।

ਟੈਲੀਮੇਟਰੀ ਵਿੱਚ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਲੀਕ ਤੋਂ ਬਚਣਾ

ਟੈਲੀਮੇਟਰੀ ਇੱਕ ਡੇਟਾ ਐਕਸਪੋਰਟ ਚੈਨਲ ਹੈ। ਇਸਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਡੇਟਾ ਵਾਂਗ ਸਲੂਕ ਕਰੋ।

ਸੰਪੂਰਨ ਤੌਰ 'ਤੇ IDs ਨੂੰ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਰੱਖੋ: ਨਾਮਾਂ, ਈਮੇਲਾਂ, ਟੋਕਨ ਜਾਂ ਕਵੇਰੀ ਪੇਲੋਡਾਂ ਦੀ ਬਜਾਏ customer_id=123 ਲਾਗ ਕਰੋ। ਲੌਗਰ/SDK ਲੇਅਰ 'ਤੇ ਰੈਡੈਕਸ਼ਨ ਅਪਲਾਈ ਕਰੋ ਅਤੇ ਆਮ ਸੀਕਰੇਟਸ (Authorization ਹੈਡਰ, API ਕੀ) ਨੂੰ ਬਲਾਕਲਿਸਟ ਕਰੋ। ਸਪੋਰਟ ਵਰਕਫਲੋਜ਼ ਲਈ ਕਿਸੇ ਵੀ ਡੀਬੱਗ ਪੇਲੋਡ ਨੂੰ ਇਕ ਵੱਖਰੀ, ਐਕਸੈਸ-ਕੰਟਰੋਲ ਕੀਤੀ ਪਰਣਾਲੀ ਵਿੱਚ ਰੱਖੋ—ਸਾਂਝੇ ਲੌਗਾਂ ਵਿੱਚ ਨਹੀਂ।

ਟੀਅਰ ਮੁਤਾਬਕ SLOs (ਔਰ ਵਾਅਦੇ ਨਾ ਕਰੋ)

ਉਹ SLOs ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹੋ। ਪੇਮਿਯਮ ਟੇਨੈਂਟਾਂ ਨੂੰ ਤੰਗ ਲੈਟੈਂਸੀ/ਏਰਰ ਬਜਟ ਮਿਲ ਸਕਦੇ ਹਨ, ਪਰ ਸਿਰਫ ਜੇ ਤੁਸੀਂ ਨਿਯੰਤਰਣ ਵੀ ਰੱਖਦੇ ਹੋ (ਰੇਟ ਲਿਮਿਟ, ਵਰਕਲੋਡ ਅਲੱਗ ਕੀਤਾ, ਪ੍ਰਾਥਮਿਕਤਾ ਕਤਾਰਾਂ)। ਟੀਅਰ SLOs ਨੂੰ ਟਾਰਗਟ ਵਜੋਂ ਪ੍ਰਕਾਸ਼ਤ ਕਰੋ, ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਟੀਅਰ ਅਤੇ ਕੁਝ ਚੁਣਿੰਦੀਆਂ ਉੱਚ-ਮੁੱਲ ਵਾਲੀਆਂ ਟੇਨੈਂਟਾਂ ਲਈ ਟਰੈਕ ਕਰੋ।

ਆਨ-ਕਾਲ ਰਨਬੁੱਕਸ: ਬਹੁ-ਕਿਰਾਏਦਾਰ SaaS ਵਿੱਚ ਆਮ ਘਟਨਾਵਾਂ

ਤੁਹਾਡੇ ਰਨਬੁੱਕਸ "ਪ੍ਰਭਾਵਿਤ ਟੇਨੈਂਟ(ਾਂ) ਦੀ ਪਛਾਣ" ਨਾਲ ਸ਼ੁਰੂ ਕਰਨ ਅਤੇ ਫਿਰ ਸਭ ਤੋਂ ਤੇਜ਼ ਅਲੱਗ ਕਰਨ ਵਾਲੀ ਕਾਰਵਾਈ ਦਰਸਾਉਣੀ ਚਾਹੀਦੀ ਹੈ:

1. ਨੋਇਜ਼ੀ ਨੇਬਰ: ਟੇਨੈਂਟ ਨੂੰ throttle ਕਰੋ, ਭਾਰੀ ਜੌਬਾਂ ਨੂੰ ਰੋਕੋ, ਜਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਘੱਟ-ਪ੍ਰਾਥਮਿਕਤਾ ਕਤਾਰ ਵਿੱਚ ਮੂਵ ਕਰੋ।
2. DB ਹੌਟਸਪਾਟ/ਰੰਵੇਅ ਕਵੇਰੀਜ਼: ਕਵੇਰੀ timeout ਚਾਲੂ ਕਰੋ, ਟੋਪ ਕਵੇਰੀਜ਼ ਨੂੰ ਟੇਨੈਂਟ ਅਨੁਸਾਰ ਜਾਂਚੋ, ਇੰਡੈਕਸ ਲਗਾਓ ਜਾਂ ਐਂਡਪੌਇੰਟ 'ਤੇ ਸੀਮਾ ਲਗਾਓ।
3. ਟੇਨੈਂਟ ਸੰਦਰਭ ਬੱਗ (ਡੇਟਾ ਮਿਲਾਉ): ਤੁਰੰਤ ਫੀਚਰ ਫਲੈਗ ਜਾਂ ਐਂਡਪੌਇੰਟ ਨੂੰ ਅਣਚਾਲੂ ਕਰੋ ਅਤੇ ਐਕਸੈਸ ਚੈਕਾਂ ਵਿੱਚ ਟੇਨੈਂਟ ਸਕੋਪਿੰਗ ਦੀ ਪੜਤਾਲ ਕਰੋ।
4. ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ ਢੇਰ: ਪ੍ਰਤੀ-ਟੇਨੈਂਟ ਕਤਾਰਾਂ ਨੂੰ ਡਰੇਨ ਕਰੋ, concurrency ਕੈਪ ਲਗਾਓ, ਅਤੇ idempotency ਸੁਰੱਖਿਅਤ ਕਰਕੇ ਦੁਬਾਰਾ ਚਲਾਓ।

ਓਪਰੇਸ਼ਨਲ ਤੌਰ 'ਤੇ, ਮਕਸਦ ਸਧਾਰਨ ਹੈ: ਟੇਨੈਂਟ ਦੁਆਰਾ ਪਛਾਣ ਕਰੋ, ਟੇਨੈਂਟ ਦੁਆਰਾ ਘੇਰਨ (Contain) ਕਰੋ, ਅਤੇ ਬਿਨਾਂ ਸਾਰੇ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤੇ ਬਹਾਲ ਕਰੋ।

ਡਿਪਲੋਇਮੈਂਟ, ਮਾਈਗ੍ਰੇਸ਼ਨ, ਅਤੇ ਟੇਨੈਂਟ-ਦਰ-ਟੇਨੈਂਟ ਰੀਲੀਜ਼

ਬਹੁ-ਕਿਰਾਏਦਾਰ SaaS ਸ਼ਿਪਿੰਗ ਦੀ ਲੈਵ ਨੂੰ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਤੁਸੀਂ ਕੋਈ "ਐਪ" ਨਾਂਹੀਂ ਡਿਪਲੋ ਕਰ ਰਹੇ—ਤੁਸੀਂ ਸ਼ੇਅਰ ਕੀਤੇ ਰਨਟਾਈਮ ਅਤੇ ਡੇਟਾ ਪਾਥਾਂ ਨੂੰ ਡਿਪਲੋ ਕਰ ਰਹੇ ਹੋ ਜੋ ਕਈ ਗਾਹਕਾਂ ਤੇ ਨਿਰਭਰ ਹਨ। ਮਨੋਰਥ ਨਵੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇਣ ਹੈ ਬਿਨਾਂ ਹਰ ਟੇਨੈਂਟ ਉੱਤੇ ਇਕੱਠੇ ਬਿਗ-ਬੈਂਗ ਅਪਗ੍ਰੇਡ ਫੋਰਸ ਕੀਤੇ।

ਰੋਲਿੰਗ ਡਿਪਲੋਇਮੈਂਟ ਅਤੇ ਘੱਟ-ਡਾਊਨਟਾਈਮ ਮਾਈਗ੍ਰੇਸ਼ਨ

ਮਿਸ਼ਰਿਤ ਵਰਜ਼ਨਾਂ ਨੂੰ ਇੱਕ ਛੋਟਾ ਵਿਂਡੋ ਲਈ ਸਹਿਣਸ਼ੀਲ ਬਣਾਉਣ ਵਾਲੇ ਡਿਪਲੋਇਮੈਂਟ ਪੈਟਰਨ ਪ੍ਰਾਥਮਿਕ ਕਰੋ (blue/green, canary, rolling)। ਇਹ ਤਦ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਡੇ ਡੇਟਾਬੇਸ ਬਦਲਾਅ ਵੀ ਸਟੇਜ ਕਿਏ ਹੋਏ ਹੋਣ।

ਇੱਕ ਵਿਹਾਰਿਕ ਨਿਯਮ ਹੈ expand → migrate → contract:

• Expand: ਨਵੇਂ ਕਾਲਮ/ਟੇਬਲ/ਇੰਡੈਕਸ ਸ਼ਾਮਿਲ ਕਰੋ ਬਿਨਾਂ ਮੌਜੂਦਾ ਕੋਡ ਨੂੰ ਟੁੱਟਣ ਦੇ।
• Migrate: ਡੇਟਾ ਨੂੰ ਬੈਚਾਂ ਵਿੱਚ ਬੈਕਫਿੱਲ ਕਰੋ (ਅਕਸਰ ਪ੍ਰਤੀ-ਟੇਨੈਂਟ) ਅਤੇ ਸੱਫਾਈ ਕਰੋ।
• Contract: ਸਾਰੇ ਐਪ ਇਨਸਟੈਂਸ ਇਹ ਵਰਤੋਂ ਨਾ ਕਰਨ ਲਗਣ, ਤਦ ਪੁਰਾਣੇ ਫੀਲਡ ਹਟਾਓ।

ਹੌਟ ਟੇਬਲਾਂ ਲਈ, ਬੈਕਫਿੱਲ ਨੂੰ ਅਨੁਕੂਲ ਤਰੀਕੇ ਨਾਲ ਕਰੋ (ਅਤੇ throttle) ਨਹੀਂ ਤਾਂ ਤੁਸੀਂ ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੌਰਾਨ ਖੁਦ ਨੋਇਜ਼ੀ-ਨੇਬਰ ਘਟਨਾ ਬਣਾਉਂਗੇ।

ਟੇਨੈਂਟ-ਸਤਰ ਫੀਚਰ ਫਲੈਗ ਸੁਰੱਖਿਅਤ ਰੋਲਆਊਟ

ਟੇਨੈਂਟ-ਸਤਰ ਫੀਚਰ ਫਲੈਗ ਤੁਹਾਨੂੰ ਕੋਡ ਨੂੰ ਗਲੋਬਲੀ ਸ਼ਿਪ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦੇ ਹਨ ਜਦੋਂ ਕਿ ਵਿਵਹਾਰ ਨੂੰ ਚੁਣੌਤੀ ਤੌਰ 'ਤੇ ਕੁਝ ਟੇਨੈਂਟਾਂ ਲਈ ਹੀ ਐਨੇਬਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਇਸ ਨਾਲ ਸਹਾਇਤਾ ਮਿਲਦੀ ਹੈ:

• ਕੁਝ ਟੇਨੈਂਟਾਂ ਲਈ ਆਰੰਭਕ ਪਹੁੰਚ ਪ੍ਰੋਗਰਾਮ
• ਪ੍ਰਭਾਵਿਤ ਟੇਨੈਂਟਾਂ ਲਈ ਫੀਚਰ ਬੰਦ ਕਰਕੇ ਤੇਜ਼ ਰੋਲਬੈਕ
• ਡਿਪਲੋਇਮੈਂਟ ਨੂੰ ਫੋਰਕ ਕੀਤੇ ਬਿਨਾਂ A/B ਪ੍ਰਯੋਗ

ਫਲੈਗ ਸਿਸਟਮ ਨੂੰ ਆਡੀਟਯੋਗ ਬਣਾਓ: ਕਿਸ ਨੇ ਕਦੋਂ ਤੇ ਕਿਸ ਟੇਨੈਂਟ ਲਈ ਅਨੁਮੋਦਿਤ ਕੀਤਾ।

ਵਰਜ਼ਨਿੰਗ ਅਤੇ ਬੈਕਵਰਡ ਕੰਪੈਟਬਿਲਿਟੀ ਦੀਆਂ ਉਮੀਦਾਂ

ਕੁਝ ਟੇਨੈਂਟਾਂ ਦੇ ਕਵਾਂਫਿਗਰੇਸ਼ਨ, ਇੰਟੇਗ੍ਰੇਸ਼ਨ, ਜਾਂ ਵਰਤੋਂ ਪੈਟਰਨ ਲੈਗ ਹੋ ਸਕਦੇ ਹਨ। APIs ਅਤੇ ਇਵੈਂਟਾਂ ਨੂੰ ਸਾਫ਼ ਵਰਜ਼ਨਿੰਗ ਨਾਲ ਡਿਜ਼ਾਈਨ ਕਰੋ ਤਾਂ ਜੋ ਨਵੇਂ ਪ੍ਰੋਡੀ🇳ਸਰਾਂ ਪੁਰਾਣੇ ਉਪਭੋਗਤਿਆਂ ਨੂੰ ਤੋੜਨ ਨਾ।

ਅੰਦਰੂਨੀ ਉਮੀਦਾਂ:

• ਮਾਈਗਰੇਸ਼ਨ ਵਿੰಡੋ ਦੌਰਾਨ ਨਵੀਆਂ ਅਤੇ ਪੁਰਾਣੀਆਂ ਸ਼ੇਪਾਂ ਦੋਹਾਂ ਨੂੰ ਪੜ੍ਹਨਾ ਚਾਹੀਦਾ ਹੈ।
• ਡੀਪ੍ਰੇਕੇਸ਼ਨ ਲਈ ਇੱਕ ਪ੍ਰਕਾਸ਼ਿਤ ਟਾਈਮਲਾਈਨ ਚਾਹੀਦੀ ਹੈ (ਇਹ ਅੰਦਰੂਨੀ ਨੋਟਸ ਨਾਲ ਗਾਹਕ ਈਮੇਲ ਟੈంపਲੇਟ ਹੋ ਸਕਦੀ ਹੈ)।

ਟੇਨੈਂਟ-ਵਿਸ਼ੇਸ਼ ਕੰਫਿਗਰੇਸ਼ਨ ਪ੍ਰਬੰਧਨ

ਟੇਨੈਂਟ ਕੰਫਿਗ ਨੂੰ ਇੱਕ ਉਤਪਾਦ ਸਤਹ ਸਮਝੋ: ਇਸਨੂੰ ਵੈਧਤਾ, ਡਿਫੌਲਟ ਅਤੇ ਚੇਨਜ ਹਿਸਟਰੀ ਦੀ ਲੋੜ ਹੈ।

ਕੰਫਿਗਰੇਸ਼ਨ ਨੂੰ ਕੋਡ ਤੋਂ ਵੱਖ ਰੱਖੋ (ਅਤੇ ਸੰਭਵ ਤੌਰ 'ਤੇ ਰਨਟਾਈਮ ਸੀਕਰੇਟਸ ਤੋਂ ਵੀ) ਅਤੇ ਜਦੋਂ ਕੰਫਿਗ ਗਲਤ ਹੋਵੇ ਤਾਂ ਇੱਕ ਸੇਫ-ਮੋਡ ਫਾਲਬੈਕ ਸਕੀਮ ਮਿਲੇ। ਇੱਕ ਹਲਕਾ-ਫਰਮਾ ਅੰਦਰੂਨੀ ਪੇਜ ਜਿਵੇਂ settings/tenants ਇੰਸੀਡੈਂਟ ਜਵਾਬ ਦੌਰਾਨ ਅਤੇ ਸਟੇਜਡ ਰੋਲਆਊਟ ਵਿੱਚ ਘੰਟੇ ਬਚਾ ਸਕਦਾ ਹੈ।

AI-ਉਤਪੰਨ ਆਰਕੀਟੈਕਚਰ ਕਿਵੇਂ ਮਦਦ ਕਰਦੇ ਹਨ (ਅਤੇ ਉਨ੍ਹਾਂ ਦੀਆਂ ਸੀਮਾਵਾਂ)

AI ਸ਼ੁਰੂਆਤੀ ਆਰਕੀਟੈਕਚਰ ਸੋਚ ਨੂੰ ਤੇਜ਼ ਕਰ ਸਕਦਾ ਹੈ ਬਹੁ-ਕਿਰਾਏਦਾਰ SaaS ਲਈ, ਪਰ ਇਹ ਇੰਜੀਨੀਅਰਿੰਗ ਫੈਸਲਾ, ਟੈਸਟਿੰਗ ਜਾਂ ਸੁਰੱਖਿਆ ਸਮੀਖਿਆ ਦਾ ਬਦਲ ਨਹੀਂ ਹੈ। ਇਸਨੂੰ ਇੱਕ ਉੱਚ-ਗੁਣਵੱਤਾ ਵਾਲਾ brainstorming ਸਾਥੀ ਸਮਝੋ ਜੋ ਡਰਾਫਟ ਬਣਾਉਂਦਾ—ਫਿਰ ਹਰ ਅਨੁਮਾਨ ਦੀ ਜਾਂਚ ਕਰੋ।

AI-ਉਤਪੰਨ ਆਰਕੀটੈਕਚਰ ਨੂੰ ਕੀ (ਅਤੇ ਕੀ ਨਹੀਂ) ਕਰਨਾ ਚਾਹੀਦਾ

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

ਜਿਹੜੇ ਇਨਪੁੱਟ ਮੈਟਰ ਕਰਦੇ ਹਨ: ਲੋੜਾਂ, ਸੀਮਾਵਾਂ, ਜੋਖਮ, ਵਾਧਾ

ਆਉਟਪੁਟ ਦੀ ਗੁਣਵੱਤਾ ਉਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਇਸਨੂੰ ਦਿੱਸਦੇ ਹੋ। ਮਦਦਗਾਰ ਇਨਪੁੱਟ ਵਿੱਚ ਸ਼ਾਮਿਲ ਹਨ:

• ਮੌਜੂਦਾ ਟੇਨੈਂਟ ਗਿਣਤੀ ਅਤੇ 12–24 ਮਹੀਨਿਆਂ ਵਿੱਚ ਉਮੀਦ ਕੀਤੀ ਗਿਣਤੀ, ਅਤੇ ਪ੍ਰਤੀ-ਟੇਨੈਂਟ ਡੇਟਾ ਵਾਲੀਅم ਦੀ ਉਮੀਦ
• ਅਲੱਗਤਾ ਦੀਆਂ ਲੋੜਾਂ (ਕॉनਟ੍ਰੈਕਚੂਅਲ, ਨਿਯਮਤ, ਗਾਹਕ ਦੀਆਂ ਉਮੀਦਾਂ)
• ਬਜਟ ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਸਮਰੱਥਾ (ਆਨ-ਕਾਲ ਮੈਚਿਊਰਟੀ, SRE ਸਹਿਯੋਗ, ਟੂਲਿੰਗ)
• ਲੈਟੈਂਸੀ ਟਾਰਗਟ, ਪੀਕ ਯੂਜ਼ੇਜ ਪੈਟਰਨ, ਅਤੇ ਟੇਨੈਂਟ ਮੁਤਾਬਕ ਬਰਸਟਨੀਐਸ
• ਜੋਖਮ ਸਹਿਣਸ਼ੀਲਤਾ: ਇੱਕ ਟੇਨੈਂਟ ਕਿਸ ਹੱਦ ਤੱਕ ਹੋਰਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦਾ ਹੈ?

AI ਨੂੰ ਪੈਟਰਨ ਵਿਕਲਪਾਂ ਅਤੇ ਟਰੇਡ-ਆਫ਼ ਦੇ ਨਾਲ ਵਰਤਣਾ

2–4 ਉਮੀਦਵਾਰ ਡਿਜ਼ਾਈਨ ਮੰਗੋ (ਉਦਾਹਰਨ: ਡੇਟਾਬੇਸ-ਪਰ-ਟੇਨੈਂਟ, ਸਕੀਮਾ-ਪਰ-ਟੇਨੈਂਟ, ਰੋ-ਲੈਵਲ ਅਲੱਗਤਾ) ਅਤੇ ਟਰੇਡ-ਆਫ਼ ਦੀ ਇੱਕ ਸਪਸ਼ਟ ਸਾਰਣੀ ਮੰਗੋ: ਲਾਗਤ, ਓਪਰੇਸ਼ਨਲ ਜਟਿਲਤਾ, ਬਲਾਸਟ-ਰੇਡੀਅਸ, ਮਾਈਗ੍ਰੇਸ਼ਨ ਕੌਸ਼ਿਸ਼, ਅਤੇ ਸਕੇਲਿੰਗ ਸੀਮਾ। AI ਉਹ ਗੋਟਚਾਜ਼ ਲਿਸਟ ਕਰਨ ਵਿੱਚ ਚੰਗਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਆਪਣੀ ਟੀਮ ਲਈ ਡਿਜ਼ਾਈਨ ਪ੍ਰਸ਼ਨਾਂ ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹੋ।

ਜੇ ਤੁਸੀਂ "ਡ੍ਰਾਫਟ ਆਰਕੀਟੈਕਚਰ" ਤੋਂ ਵੱਕਰੀ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰ ਰਹੇ ਪ੍ਰੋਟੋਟਾਈਪ ਵੱਲ ਜਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ vibe-coding ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ Koder.ai ਤੁਹਾਡੀ ਗੱਲਬਾਤ ਰਾਹੀਂ ਉਹ ਚੋਣਾਂ ਇੱਕ ਅਸਲ ਐਪ ਸਕੈਲਟਨ ਵਿੱਚ ਬਦਲ ਸਕਦਾ ਹੈ—ਅਕਸਰ React ਫਰੰਟਐਂਡ ਅਤੇ Go + PostgreSQL ਬੈਕਐਂਡ ਨਾਲ—ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਟੇਨੈਂਟ ਸੰਦਰਭ ਪ੍ਰੋਪੈਗੇਸ਼ਨ, ਰੇਟ-ਲਿਮਿਟ ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਵਰਕਫਲੋਜ਼ ਦੀ ਜਾਂਚ ਕਰ ਸਕਦੇ ਹੋ। ਯੋਜਨਾ ਬਣਾਉਣ ਵਾਲੇ ਮੋਡ ਅਤੇ snapshots/rollback ਵਰਗੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਲਾਭਦਾਇਕ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਬਹੁ-ਕਿਰਾਏਦਾਰ ਡੇਟਾ ਮਾਡਲਾਂ 'ਤੇ ਦੁਹਰਾਈ ਕਰ ਰਹੇ ਹੋ।

ਖਤਰੇ-ਮਾਡਲ ਅਤੇ ਚੈੱਕਲਿਸਟ ਆਉਟਪੁਟ ਲਈ AI ਦਾ ਵਰਤੋਂ

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

ਤੁਹਾਡੇ ਟੀਮ ਲਈ ਇੱਕ ਵਿਹਾਰਿਕ ਚੁਣੌਤੀ ਚੈੱਕਲਿਸਟ

ਬਹੁ-ਕਿਰਾਏਦਾਰ ਅਪ੍ਰੋਚ ਚੁਣਨਾ "ਸਭ ਤੋਂ ਵਧੀਆ ਅਭਿਆਸ" ਤੋਂ ਘੱਟ ਤੇ "ਫਿੱਟ" ਬਾਰੇ ਜ਼ਿਆਦਾ ਹੈ: ਤੁਹਾਡੀ ਡੇਟਾ ਸੰਵੇਦਨशीलਤਾ, ਤੁਹਾਡਾ ਵਾਧਾ ਦਰ, ਅਤੇ ਤੁਸੀਂ ਕਿੰਨਾ ਓਪਰੇਸ਼ਨਲ ਜਟਿਲਤਾ ਸਹਿ ਸਕਦੇ ਹੋ।

ਕਦਮ-ਦਰ-ਕਦਮ ਚੈੱਕਲਿਸਟ (ਇੱਕ 30-ਮਿੰਟ ਦੀ ਵਰਕਸ਼ਾਪ ਵਿੱਚ ਵਰਤੋਂ)

1. ਡੇਟਾ: ਕਿਹੜਾ ਡੇਟਾ ਟੇਨੈਂਟਾਂ ਵਿਚਕਾਰ ਸਾਂਝਾ ਹੈ (ਜੇ ਕੋਈ)? ਕਿਹੜਾ ਡੇਟਾ ਕਦੇ ਵੀ ਇਕੱਠਾ ਨਹੀਂ ਹੋ ਸਕਦਾ?

2. ਪਹਿਚਾਨ: ਟੇਨੈਂਟ ਪਹਿਚਾਨ ਕਿੱਥੇ ਰਹਿੰਦੀ ਹੈ (invite links, domains, SSO claims)? ਹਰ ਰਿਕਵੈਸਟ 'ਤੇ ਟੇਨੈਂਟ ਸੰਦਰਭ ਕਿਵੇਂ ਸਥਾਪਤ ਹੁੰਦਾ ਹੈ?

3. ਅਲੱਗਤਾ: ਆਪਣੀ ਡਿਫੌਲਟ ਅਲੱਗਤਾ ਪੱਧਰ ਨਿਰਧਾਰਿਤ ਕਰੋ (ਰੋ/ਸਕੀਮਾ/ਡੇਟਾਬੇਸ) ਅਤੇ ਛੁੱਟੀਆਂ ਦਰਜ ਕਰੋ (ਜਿਵੇਂ, ਐਂਟਰਪ੍ਰਾਈਜ਼ ਗ੍ਰਾਹਕਾਂ ਲਈ ਕਠੋਰ ਅਲੱਗਤਾ)।

4. ਸਕੇਲਿੰਗ: ਪਹਿਲੀ ਸਕੇਲਿੰਗ ਦਬਾਅ ਦੀ ਪਛਾਣ ਕਰੋ (ਸਟੋਰੇਜ, ਰੀਡ ਟ੍ਰੈਫਿਕ, ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ, ਐਨਾਲਿਟਿਕਸ) ਅਤੇ ਉਸਨੂੰ ਨਿਭਾਉਣ ਲਈ ਸਭ ਤੋਂ ਸਧਾਰਨ ਪੈਟਰਨ ਚੁਣੋ।

ਇੰਜੀਨੀਅਰਾਂ ਅਤੇ ਸੁਰੱਖਿਆ ਸਮੀਖਿਆਕਰਤਾ ਨਾਲ ਪੁੱਛਣ ਲਈ ਸਵਾਲ

• ਇੱਕ ਡਿਵੈਲਪਰ ਫਿਲਟਰ ਭੁੱਲ ਜਾਂ ਤਾਂ ਅਸੀਂ ਕਿਵੇਂ ਕ੍ਰਾਸ-ਟੇਨੈਂਟ ਐਕਸੈਸ ਰੋਕਾਂਗੇ?
• ਪ੍ਰਤੀ-ਟੇਨੈਂਟ ਆਡੀਟ ਕਿਵੇਂ ਹੋਵੇਗਾ (ਕੌਣ, ਕਦੋਂ ਕੀ ਕੀਤਾ)?
• ਪ੍ਰਤੀ-ਟੇਨੈਂਟ ਡੇਟਾ ਮਿਟਾਉਣ ਅਤੇ ਰੀਟੇਨਸ਼ਨ ਨੂੰ ਅਸੀਂ ਕਿਵੇਂ ਹੈਂਡਲ ਕਰਾਂਗੇ?
• ਖ਼ਰਾਬ ਮਾਈਗ੍ਰੇਸ਼ਨ ਜਾਂ runaway ਕਵੇਰੀ ਦਾ ਬਲਾਸਟ-ਰੇਡੀਅਸ ਕੀ ਹੈ?
• ਕੀ ਅਸੀਂ ਪ੍ਰਤੀ-ਟੇਨੈਂਟ ਸਰੋਤਾਂ ਨੂੰ throttle, rate-limit, ਅਤੇ ਬਜਟ ਕਰ ਸਕਦੇ ਹਾਂ?

ਗੁਲਾਬੀ ਝੰਡੇ ਜਿਨ੍ਹਾਂ ਨੂੰ ਗਹਿਰੇ ਡਿਜ਼ਾਈਨ ਦੀ ਲੋੜ ਹੈ

• "ਅਸੀਂ ਟੇਨੈਂਟ ਚੈਕ ਬਾਅਦ ਜੋੜਾਂਗੇ"।
• ਸਾਂਝੇ ਐਡਮਿਨ ਟੂਲ ਜੋ ਬਿਨਾਂ ਕਠੋਰ ਨਿਯੰਤਰਣ ਦੇ ਸਭ ਕੁਝ ਵੇਖ ਸਕਦੇ ਹਨ।
• ਪ੍ਰਤੀ-ਟੇਨੈਂਟ ਬੈਕਅੱਪ/ਰੀਸਟੋਰ ਜਾਂ ਇਨਸਿਡੈਂਟ ਰਿਸਪਾਂਸ ਲਈ ਕੋਈ ਯੋਜਨਾ ਨਹੀਂ।
• ਇੱਕ ਇਕੱਲੀ ਕਤਾਰ/ਵਰਕਰ ਪੂਲ ਬਿਨਾਂ ਪ੍ਰਤੀ-ਟੇਨੈਂਟ ਨਿਆਂਯੁਕਤਤਾ ਦੇ।

ਨਮੂਨਾ "ਅਗਲਾ ਸਿਫਾਰਸ਼ੀ ਕਾਰਵਾਈ" ਸੰਖੇਪ

ਸਿਫਾਰਸ਼: ਰੋ-ਲੈਵਲ ਅਲੱਗਤਾ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ + ਸਖ਼ਤ ਟੇਨੈਂਟ-ਸੰਦਰਭ ਲਾਗੂ ਕਰੋ, ਪ੍ਰਤੀ-ਟੇਨੈਂਟ throttle ਜੋੜੋ, ਅਤੇ ਉੱਚ-ਜੋਖਮ ਟੇਨੈਂਟਾਂ ਲਈ ਸਕੀਮਾ/ਡੇਟਾਬੇਸ ਅਲੱਗਤਾ ਵੱਲ ਅਪਗ੍ਰੇਡ ਰਾਹ ਨਿਰਧਾਰਤ ਕਰੋ।

ਅਗਲੇ ਕਦਮ (2 ਹਫ਼ਤੇ): ਟੇਨੈਂਟ ਬਾਉਂਡਰੀਆਂ ਲਈ ਖਤਰਾ-ਮਾਡਲ ਤਿਆਰ ਕਰੋ, ਇਕ ਐਨਡਪੌਇੰਟ 'ਤੇ ਲਾਗੂ ਕਰਨ ਲਈ ਬਹਿਸ-ਮੁਕਾਬਲਾ ਪ੍ਰੋਟੋਟਾਈਪ ਬਣਾਓ, ਅਤੇ ਸਟੇਜਿੰਗ ਨਕਲ 'ਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਰਿਹਰਸਲ ਚਲਾਓ। ਰੋਲਆਊਟ ਗਾਈਡ ਲਈ ਸੰਦਰਭ ਵੇਖੋ tenant-release-strategies.