ਜਾਣੋ ਕਿ ਘਟਨਾਵਾਂ ਦੌਰਾਨ ਪੜ੍ਹਨ-ਕੇਵਲ ਮੋਡ ਕਿਵੇਂ ਲਿਖਤਾਂ ਨੂੰ ਰੋਕਦਾ ਹੈ, ਮੁੱਖ ਪੜ੍ਹਾਈਆਂ ਨੂੰ ਜਿਊਂਦਾ ਰੱਖਦਾ ਹੈ ਅਤੇ ਜਦੋਂ ਡੇਟਾਬੇਸ ਦਬਾਅ ਵਿੱਚ ਹੋਵੇ ਤਾਂ UI ਵਿੱਚ ਸਪਸ਼ਟ ਸੰਦੇਸ਼ ਕਿਵੇਂ ਦਿਖਾਉਂਦਾ ਹੈ।
ਜਦੋਂ ਤੁਹਾਡਾ ਡੇਟਾਬੇਸ ਓਵਰਲੋਡ ਹੋ ਜਾਂਦਾ ਹੈ, ਯੂਜ਼ਰ ਅਕਸਰ ਕੋਈ ਸਾਫ਼ "ਡਾਊਨ" ਸੁਨੇਹਾ ਨਹੀਂ ਵੇਖਦੇ। ਉਹ ਟਾਇਮਆਊਟ, ਅਧ-ਭਰੇ ਪੇਜ਼, ਹਮੇਸ਼ਾ ਘੁੰਮਦੇ ਬਟਨ ਅਤੇ ਕਈ ਵਾਰੀ ਕੰਮ ਕਰਨ ਅਤੇ ਕਈ ਵਾਰੀ ਫੇਲ ਹੋਣ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ ਵੇਖਦੇ ਹਨ। ਇੱਕ ਸੇਵ ਇੱਕ ਵਾਰੀ ਸਫਲ ਹੋ ਸਕਦੀ ਹੈ, ਫਿਰ ਅਗਲੀ ਵਾਰੀ "ਕੁਝ ਗਲਤ ਹੋ ਗਿਆ" ਦੀ ਗਲਤੀ ਆ ਸਕਦੀ ਹੈ। ਇਹ ਅਣਪ੍ਰਿਡਿਕਟੇਬਿਲਟੀ ਹੀ ਘਟਨਾਵਾਂ ਨੂੰ ਹਲਚਲ ਭਰਾ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੀ ਹੈ।
ਆਮ ਤੌਰ 'ਤੇ ਪਹਿਲਾਂ ਟੁਟਣ ਵਾਲੇ ਰਸਤੇ ਲਿਖਣ-ਭਰਪੂਰ ਹੁੰਦੇ ਹਨ: ਰਿਕਾਰਡ ਸੰਪਾਦਨ, ਚੈਕਆਉਟ ਫਲੋ, ਫਾਰਮ ਸਬਮਿਟ, ਬੈਕਗ੍ਰਾਊਂਡ ਅਪਡੇਟ ਅਤੇ ਜੋ ਵੀ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਅਤੇ ਲਾਕਸ ਮੰਗਦਾ ਹੈ। ਦਬਾਅ ਹੇਠਾਂ, ਲਿਖਤਾਂ ਧੀਮੀਆਂ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਉਹ ਇਕ-ਦੂਜੇ ਨੂੰ ਰੋਕਦੀਆਂ ਹਨ ਅਤੇ ਲਾਕਸ ਰੱਖ ਕੇ ਪੜ੍ਹਨੀਆਂ ਨੂੰ ਵੀ ਧੀਮਾ ਕਰ ਸਕਦੀਆਂ ਹਨ।
ਅਣਿਰਧਾਰਿਤ ਤਰ੍ਹਾਂ ਦੀਆਂ ਗਲਤੀਆਂ ਇੱਕ ਨਿਯੰਤਰਿਤ ਪਰਿਧੀ ਨਾਲੋਂ ਬੁਰੀਆਂ ਲਗਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਯੂਜ਼ਰ ਨੂੰ ਪਤਾ ਨਹੀਂ ਹੁੰਦਾ ਅਗਲਾ ਕਦਮ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਉਹ ਦੁਹਰਾਉਂਦੇ ਹਨ, ਰਿਫਰੇਸ਼ ਕਰਦੇ ਹਨ, ਫਿਰ ਦਬਾਉਂਦੇ ਹਨ, ਅਤੇ ਹੋਰ ਲੋਡ ਬਣਾਉਂਦੇ ਹਨ। ਸਪੋਰਟ ਟਿਕਟ ਵੱਧ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਸਿਸਟਮ "ਕਿਸੇ ਹੱਦ ਤੱਕ ਚੱਲ ਰਿਹਾ ਹੈ," ਪਰ ਕਿਸੇ ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ।
ਪੜ੍ਹਨ-ਕੇਵਲ ਮੋਡ ਦਾ ਮਕਸਦ ਕੁਆਲਟੀ ਨਹੀਂ ਹੁੰਦਾ। ਮਕਸਦ ਸਭ ਤੋਂ ਅਹੰਕਾਰਪੂਰਕ ਹਿੱਸਿਆਂ ਨੂੰ ਵਰਤਯੋਗ ਰੱਖਣਾ ਹੈ: ਮੁੱਖ ਰਿਕਾਰਡ ਦੇਖਣਾ, ਖੋਜਣਾ, ਸਥਿਤੀ ਚੈੱਕ ਕਰਨਾ ਅਤੇ ਲੋੜੀਂਦੇ ਡਾਟਾ ਡਾਊਨਲੋਡ ਕਰਨਾ। ਤੁਸੀਂ ਜਾਣਬੂਝ ਕੇ ਖਤਰਨਾਕ ਕਾਰਵਾਈਆਂ (ਲਿਖਤਾਂ) ਨੂੰ ਰੋਕ ਦਿੰਦੇ ਹੋ ਤਾਂ ਜੋ ਡੇਟਾਬੇਸ ਠੀਕ ਹੋ ਸਕੇ ਅਤੇ ਬਾਕੀ ਪੜ੍ਹਨੀਆਂ ਜ਼ਿਆਦਾ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਬਣੀ ਰਹਿਣ।
ਉਮੀਦਾਂ ਨੂੰ ਸਪਸ਼ਟ ਰੱਖੋ। ਇਹ ਅਸਥਾਈ ਸੀਮਾ ਹੈ, ਅਤੇ ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਡਾਟਾ ਮਿਟਾਇਆ ਜਾ ਰਿਹਾ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਕੇਸਾਂ ਵਿੱਚ ਯੂਜ਼ਰ ਦਾ ਮੌਜੂਦਾ ਡੇਟਾ ਸੁਰੱਖਿਅਤ ਰਹਿੰਦਾ ਹੈ—ਸਿਸਟਮ ਸਿਰਫ਼ ਤਬਦੀਲੀਆਂ ਨੂੰ ਰੋਕ ਰਿਹਾ ਹੈ ਜਦ ਤੱਕ ਡੇਟਾਬੇਸ ਫਿਰ ਸਿਹਤਮੰਦ ਨਹੀਂ ਹੋ ਜਾਂਦਾ।
ਘਟਨਾਵਾਂ ਦੌਰਾਨ ਪੜ੍ਹਨ-ਕੇਵਲ ਮੋਡ ਇੱਕ ਅਸਥਾਈ ਹਾਲਤ ਹੈ ਜਿਸ ਵਿੱਚ ਤੁਹਾਡਾ ਉਤਪਾਦ ਦੇਖਣ ਲਈ ਵਰਤਯੋਗ ਰਹਿੰਦਾ ਹੈ ਪਰ ਕੋਈ ਵੀ ਐਸੀ ਕਾਰਵਾਈ ਜਿਸ ਨਾਲ ਡੇਟਾ ਬਦਲਦਾ ਹੈ, ਉਹ ਇਨਕਾਰ ਕਰ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ। ਮਕਸਦ ਸਧਾਰਨ ਹੈ: ਸੇਵਾ ਨੂੰ ਸਹਾਇਕ ਬਣਾਈ ਰੱਖਣਾ ਜਦੋਂ ਤੁਸੀਂ ਡੇਟਾਬੇਸ ਨੂੰ ਵਧੇਰੇ ਕੰਮ ਤੋਂ ਬਚਾ ਰਹੇ ਹੋ।
ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਲੋਕ ਅਜੇ ਵੀ ਚੀਜ਼ਾਂ ਵੇਖ ਸਕਦੇ ਹਨ ਪਰ ਉਹ ਐਸੀਆਂ ਤਬਦੀਲੀਆਂ ਨਹੀਂ ਕਰ ਸਕਦੇ ਜੋ ਲਿਖਤਾਂ ਨੂੰ ਟ੍ਰਿਗਰ ਕਰਦੀਆਂ। ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਬ੍ਰਾਊਜ਼ਿੰਗ, ਖੋਜ, ਫਿਲਟਰਿੰਗ ਅਤੇ ਰਿਕਾਰਡ ਖੋਲ੍ਹਣ ਵਰਗੀਆਂ ਕਾਰਵਾਈਆਂ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ। ਫਾਰਮਾਂ ਨੂੰ ਸੇਵ ਕਰਨਾ, ਸੈੱਟਿੰਗਸ ਸੋਧਣਾ, ਟਿੱਪਣੀਆਂ ਪੋਸਟ ਕਰਨਾ, ਫਾਈਲਾਂ ਅੱਪਲੋਡ ਕਰਨਾ ਜਾਂ ਨਵੀਂ ਖਾਤਾ ਬਣਾਉਣਾ ਰੋਕ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।
ਇੱਕ عملی ਢੰਗ ਨਾਲ ਸੋਚਣ ਲਈ: ਜੇ ਕੋਈ ਕਾਰਵਾਈ ਕਿਸੇ ਰੋ ਨੂੰ ਅੱਪਡੇਟ ਕਰਦੀ ਹੈ, ਨਵਾਂ ਰੋ ਬਣਾਉਂਦੀ ਹੈ, ਰੋ ਮਿਟਾਉਂਦੀ ਹੈ ਜਾਂ ਕਿਉਂਕਿ ਕੁਝ ਲਿਖਣ ਵਾਲੇ ਕਮਾਂਡ ਨੂੰ ਕਤਾਰ 'ਚ ਰੱਖਦੀ ਹੈ, ਤਾਂ ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਮਨਾਹੀ ਹੁੰਦੀ ਹੈ। ਬਹੁਤੀਆਂ ਟੀਮਾਂ "ਛੁਪੇ ਲਿਖਤਾਂ" ਨੂੰ ਵੀ ਰੋਕਦੀਆਂ ਹਨ—ਉਦਾਹਰਨ ਵਜੋਂ ਅਨੇਲੇਟਿਕਸ ਇਵੈਂਟ ਜੇ ਮੁੱਖ ਡੇਟਾਬੇਸ ਵਿੱਚ ਹਨ, ਸਿੰਕ੍ਰੋਨਸ ਆਡੀਟ ਲੌਗ ਜਾਂ "last seen" ਟਾਈਮਸਟੈਂਪ।
ਪੜ੍ਹਨ-ਕੇਵਲ ਮੋਡ ਉਹ ਸਮੇਂ ਸਹੀ ਹੈ ਜਦੋਂ ਪੜ੍ਹਨੀਆਂ ਅਜੇ ਵੀ ਵੱਧਤਰ ਕੰਮ ਕਰ ਰਹੀਆਂ ਹਨ ਪਰ ਲਿਖਣ ਦੀ ਲੈਟੈਂਸੀ ਵਧ ਰਹੀ ਹੈ, ਲਾਕ ਕੰਟੈਨਸ਼ਨ ਵਧ ਰਿਹਾ ਹੈ, ਜਾਂ ਲਿਖਤ-ਭਰਪੂਰ ਕੰਮ ਦੀ ਬੈਕਲਾਗ ਸਾਰਿਆਂ ਨੂੰ ਧੀਮਾ ਕਰ ਰਹੀ ਹੈ।
ਜਦੋਂ ਮੂਲ ਪੜ੍ਹਨ ਵੀ ਟਾਇਮਆਊਟ ਹੋਣ ਲੱਗੇ, ਤੁਹਾਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਆਫਲਾਈਨ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ—ਜਦੋਂ ਤੁਹਾਡਾ ਕੈਸ਼ ਆਵਸ਼ਕਤ ਚੀਜ਼ਾਂ ਸਰਵ ਕਰਨ ਵਿੱਚ ਅਸਫਲ ਹੋਵੇ ਜਾਂ ਸਿਸਟਮ ਯੂਜ਼ਰਾਂ ਨੂੰ ਭਰੋਸੇਯੋਗ ਸਥਿਤੀ ਨਹੀਂ ਦਸ ਸਕੇ।
ਇਸਦਾ ਫਾਇਦਾ ਇਹ ਹੈ ਕਿ ਲਿਖਤਾਂ ਅਕਸਰ ਇੱਕ ਸਧਾਰਨ ਪੜ੍ਹਨ ਨਾਲੋਂ ਕਾਫੀ ਮਹਿੰਗੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। ਇੱਕ ਲਿਖਤ ਇੰਡੈਕਸ, ਕਨਸਟਰੇਂਟ, ਲਾਕ ਅਤੇ ਫਾਲੋ-ਅਪ ਕੁਏਰੀਆਂ ਨੂੰ ਟ੍ਰਿਗਰ ਕਰ ਸਕਦੀ ਹੈ। ਲਿਖਤਾਂ ਰੋਕਣਾ retry-ਤਫ਼ਾਨ ਨੂੰ ਵੀ ਰੋਕਦਾ ਹੈ, ਜਿੱਥੇ ਕਲਾਇੰਟ ਅਸਫਲ ਸੇਵਾਂ ਨੂੰ ਮੁੜ-ਜਮ੍ਹਾਂ ਕਰਦੇ ਰਹਿੰਦੇ ਹਨ ਅਤੇ ਨੁਕਸਾਨ ਵਧ ਜਾਂਦਾ ਹੈ।
ਉਦਾਹਰਨ: ਇੱਕ CRM ਘਟਨਾ ਦੌਰਾਨ, ਯੂਜ਼ਰ ਅਜੇ ਵੀ ਖਾਤਿਆਂ ਨੂੰ ਖੋਜ ਸਕਦੇ ਹਨ, ਸੰਪਰਕ ਵੇਰਵੇ ਖੋਲ੍ਹ ਸਕਦੇ ਹਨ ਅਤੇ ਹਾਲੀਆ ਡੀਲ ਵੇਖ ਸਕਦੇ ਹਨ, ਪਰ Edit, Create ਅਤੇ Import ਕਾਰਵਾਈਆਂ ਨਿਸ਼ਕ੍ਰਿਯ ਹੋ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਕੋਈ ਵੀ ਸੇਵ ਬੇਨਤੀ ਤੁਰੰਤ ਸਪਸ਼ਟ ਸੁਨੇਹੇ ਨਾਲ ਰਿੱਜੈਕਟ ਕਰ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ।
ਜਦੋਂ ਤੁਸੀਂ ਘਟਨਾ ਦੌਰਾਨ ਪੜ੍ਹਨ-ਕੇਵਲ ਮੋਡ ਚਾਲੂ ਕਰਦੇ ਹੋ, ਮਕਸਦ "ਸਭ ਕੁਝ ਕੰਮ ਕਰੇ" ਨਹੀਂ ਹੁੰਦਾ। ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਕ ਸਕਰੀਨ ਲੋਡ ਹੋ ਜਾਣ, ਜਦਕਿ ਜੋ ਵੀ ਵਧੇਰੇ ਡੇਟਾਬੇਸ-ਦਬਾਅ ਪੈਦਾ ਕਰਦਾ ਹੈ ਉਹ ਤੇਜ਼ੀ ਨਾਲ ਅਤੇ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਰੁਕ ਜਾਵੇ।
ਸ਼ੁਰੂ ਕਰੋ ਉਹ ਕੁਝ ਯੂਜ਼ਰ ਕਿਰਿਆਵਾਂ ਨਾਂਮ ਦੇ ਕੇ ਜੋ ਬੁਰੇ ਦਿਨ 'ਤੇ ਵੀ ਕੰਮ ਕਰਣੀ ਚਾਹੀਦੀਆਂ ਹਨ। ਅਕਸਰ ਇਹ ਛੋਟੀ-ਛੋਟੀ ਪੜ੍ਹਨੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਤੁਰੰਤ ਫੈਸਲੇ ਨੂੰ ਅਨਲੌਕ ਕਰਦੀਆਂ ਹਨ: ਤਾਜ਼ਾ ਰਿਕਾਰਡ ਦੇਖਣਾ, ਸਥਿਤੀ ਚੈੱਕ ਕਰਨਾ, ਛੋਟੀ ਲਿਸਟ ਖੋਜਣਾ ਜਾਂ ਪਹਿਲਾਂ ਕੈਸ਼ ਕੀਤੀ ਰਿਪੋਰਟ ਡਾਊਨਲੋਡ ਕਰਨਾ।
ਫਿਰ ਸੋਚੋ ਕਿ ਕੀ ਤੁਸੀਂ ਬਿਨਾਂ ਵੱਡੇ ਨੁਕਸਾਨ ਦੇ ਰੋਕ ਸਕਦੇ ਹੋ। ਜ਼ਿਆਦਾਤਰ ਲਿਖਣ-ਰਾਸਤੇ ਇਸ ਸਮੇਂ "ਨਾਈਸ-ਟੂ-ਹੈਵ" ਸਮਝੇ ਜਾ ਸਕਦੇ ਹਨ: ਸੋਧ, ਬਲਕ ਅੱਪਡੇਟ, ਇੰਪੋਰਟ, ਟਿੱਪਣੀਆਂ, ਅਟੈਚਮੈਂਟ, ਐਨਾਲਿਟਿਕਸ ਇਵੈਂਟ ਅਤੇ ਜੋ ਵੀ ਵਾਧੂ ਕੁਏਰੀਆਂ ਟ੍ਰਿਗਰ ਕਰਦਾ ਹੈ।
ਇੱਕ ਸਧਾਰਨ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਕਾਰਵਾਈਆਂ ਨੂੰ ਤਿੰਨ ਬਾਸਕੇਟਾਂ ਵਿੱਚ ਵੰਡੋ:
ਇੱਕ ਸਮੇਂ ਦੀ ਹੱਦ ਵੀ ਨਿਯਤ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਮਿੰਟਾਂ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਕਾਫੀ ਸਖਤ ਹੋ ਸਕਦੇ ਹੋ ਅਤੇ ਲਗਭਗ ਸਾਰੀਆਂ ਲਿਖਤਾਂ ਰੋਕ ਸਕਦੇ ਹੋ। ਜੇ ਘੰਟਿਆਂ ਦੀ ਉਮੀਦ ਹੋਵੇ, ਤਾਂ ਬਹੁਤ ਹੀ ਸੀਮਤ ਸੁਰੱਖਿਅਤ ਲਿਖਤਾਂ (ਜਿਵੇਂ password resets ਜਾਂ ਆਵਸ਼ਕ ਸਥਿਤੀ ਅਪਡੇਟ) ਦੀ ਆਗਿਆ ਦੇ ਕੇ ਬਾਕੀ ਸਭ ਨੂੰ ਕਿਊ ਤੇ ਰੱਖਣ 'ਤੇ ਵਿਚਾਰ ਕਰੋ।
ਪਹਿਲਾਂ ਤਰਜੀਹ 'ਤੇ ਸਹਿਮਤ ਹੋਵੋ: ਸੁਰੱਖਿਆ ਪੂਰਨਤਾ ਤੋਂ ਉਚਿਤ ਹੈ। ਇੱਕ ਸਾਫ਼ "ਤਬਦੀਲੀਆਂ ਰੋਕ ਦਿੱਤੀਆਂ ਗਈਆਂ ਹਨ" ਸੁਨੇਹਾ ਦਿਖਾਉਣ ਨਾਲੋਂ ਇੱਕ ਅਜਿਹਾ ਲਿਖਤ ਜੋ ਅਧ-ਸਫਲ ਹੋ ਕੇ ਡਾਟਾ ਨੂੰ ਅਸੰਗਤ ਛੱਡ ਦੇਵੇ, ਉਸਨੂੰ ਆਗਿਆ ਦੇਣ ਨਾਲੋਂ ਬੇਹਤਰ ਹੈ।
ਪੜ੍ਹਨ-ਕੇਵਲ ਸਵਿੱਚ ਚਾਲੂ ਕਰਨ ਦਾ ਵਪਾਰ ਹੈ: ਹੁਣ ਘੱਟ ਫੀਚਰ, ਪਰ ਵਰਤਯੋਗ ਉਤਪਾਦ ਅਤੇ ਇੱਕ ਸਿਹਤਮੰਦ ਡੇਟਾਬੇਸ। ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਯੂਜ਼ਰਾਂ ਵੱਲੋਂ retry-ਤਫ਼ਾਨ, ਟਾਇਮਆਊਟ ਅਤੇ ਫਸੇ ਹੋਏ ਕਨੈਕਸ਼ਨਾਂ ਦਾ ਚੱਕਰ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਕਾਰਵਾਈ ਕਰੋ।
ਕੁਝ ਸਿਗਨਲਾਂ 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ ਜੋ ਤੁਸੀਂ ਇੱਕ ਵਾਕ ਵਿੱਚ ਸਮਝਾ ਸਕੋ। ਜੇ ਇੱਕੋ ਸਮੇਂ ਦੋ ਜਾਂ ਹੋਰ ਨਿਸ਼ਾਨੇ ਆ ਜਾ ਰਹੇ ਹਨ, ਤਾਂ ਇਸਨੂੰ ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਚੇਤਾਵਨੀ ਸਮਝੋ:
ਸਿਰਫ ਮੈਟਰਿਕਸ ਨੂੰ ਟਰਿਗਰ ਨਾ ਬਣਾਓ। ਇੱਕ ਮਨੁੱਖੀ ਫੈਸਲਾ ਵੀ ਹੋਵੇ: on-call ਵਿਅਕਤੀ ਘਟਨਾ ਸੂਚਨਾ ਕਰੇ ਅਤੇ read-only ਮੋਡ ਚਾਲੂ ਕਰੇ। ਇਸ ਨਾਲ ਦਬਾਅ ਦੇ ਵਿਚਕਾਰ ਵਿਚਾਰ-ਵਟਾਂਦਰੇ ਰੁਕਦੇ ਹਨ ਅਤੇ ਕਾਰਵਾਈ ਆਡੀਟ ਹੋ ਸਕਦੀ ਹੈ।
ਥ੍ਰੈਸ਼ਹੋਲਡ ਯਾਦ ਰੱਖਣ ਅਤੇ਼ ਸੰਚਾਰ ਲਈ ਆਸਾਨ ਬਣਾਓ। "Writes are paused because the database is overloaded" ਵਾਂਗ ਇੱਕ ਸਾਦਾ ਜੁਮਲਾ "we hit saturation" ਨਾਲੋਂ ਵੱਧ ਸਪਸ਼ਟ ਹੈ। ਇਹ ਵੀ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਕੌਣ ਸਵਿੱਚ ਕਰ ਸਕਦਾ ਹੈ ਤੇ ਕਿੱਥੇ ਕੰਟਰੋਲ ਹੈ।
ਮੋਡ ਦੇ ਵਿਚਕਾਰ ਚਮਕ-ਬਦਲ (flapping) ਤੋਂ ਬਚੋ। ਸਧਾਰਨ hysteresis ਰੱਖੋ: ਜਦੋਂ ਤੁਸੀਂ read-only ਚਾਲੂ ਕਰੋ, ਇੱਕ ਘੱਟੋ-ਘੱਟ ਵਿੰਡੋ (ਜਿਵੇਂ 10–15 ਮਿੰਟ) ਲਈ ਉਥੇ ਰਹੋ ਅਤੇ ਮੁੜ ਸਧਾਰਨ ਹੋਣ ਤੋਂ ਬਾਅਦ ਹੀ ਵਾਪਸ ਜਾਓ। ਇਹ ਯੂਜ਼ਰਾਂ ਨੂੰ ਫਾਰਮਾਂ ਜੋ ਇੱਕ ਵਾਰੀ ਕੰਮ ਕਰ ਰਹੀਆਂ ਹਨ ਅਤੇ ਅਗਲੇ ਪਲ ਫੇਲ ਹੋ ਰਹੀਆਂ ਹਨ ਦੇਖਣ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।
ਘਟਨਾਵਾਂ ਦੌਰਾਨ read-only ਮੋਡ ਨੂੰ ਇੱਕ ਨਿਯੰਤਰਿਤ ਬਦਲਾਅ ਵਜੋਂ ਦੇਖੋ, ਨਾ ਕਿ ਇਕ ਦੌੜ-ਭੱਜ। ਮਕਸਦ ਡੇਟਾਬੇਸ ਦੀ ਰੱਖਿਆ ਕਰਨਾ ਹੈ ਲਿਖਤਾਂ ਰੋਕ ਕੇ, ਜਦਕਿ ਸਭ ਤੋਂ ਮੁੱਲਵਾਨ ਪੜ੍ਹਨੀਆਂ ਚੱਲਦੀਆਂ ਰਹਿਣ।
ਜੇ ਸੰਭਵ ਹੋਵੇ, ਤਾਂ ਕੋਡ ਪਾਥ ਨੂੰ ਸ਼ਿਪ ਕਰੋ ਤਾਂ ਕਿ ਸਵਿੱਚ ਫਲੇਗ ਟੌਗਲ ਹੋ ਕੇ read-only ਚਾਲੂ ਕਰਨਾ ਕੇਵਲ ਇਕ ਟੌਗਲ ਹੋਵੇ, ਜਿਥੇ ਤਬਦੀਲੀ ਲਾਈਵ ਐਡੀਟ ਨਾ ਹੋਵੇ।
READ_ONLY=true. ਕਈ ਫਲੈਗ ਨਾ ਬਣਾਓ ਜੋ ਅਲੱਗ-ਅਲੱਗ ਰਹਿ ਜਾਣਗੇ।ਜਦੋਂ read-only ਚਾਲੂ ਹੋਵੇ, ਤਾਂ ਡੇਟਾਬੇਸ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਫੇਲ-ਫਾਸਟ ਕਰੋ। ਵਰਿਫਿਕੇਸ਼ਨ ਕੁਏਰੀਆਂ ਚਲਾਕੀ ਨਾਲ ਨਾ ਚਲਾਉ ਅਤੇ ਫਿਰ ਲਿਖਤ ਰੋਕੋ। ਸਭ ਤੋਂ ਤੇਜ਼ ਬਲੌਕ ਕੀਤੀ ਬੇਨਤੀ ਉਹ ਹੁੰਦੀ ਹੈ ਜੋ ਕਦੇ ਵੀ ਤੁਹਾਡੇ ਦਿਬਾਉਂਡ ਡੇਟਾਬੇਸ ਨੂੰ ਛੂਹਦੀ ਹੀ ਨਹੀਂ।
ਜਦੋਂ ਤੁਸੀਂ read-only ਚਾਲੂ ਕਰਦੇ ਹੋ, UI ਵੀ ਠੀਕ ਕਰਨ ਦੇ ਪ੍ਰਕਿਰਿਆ ਦਾ ਹਿੱਸਾ ਬਣ ਜਾਂਦਾ ਹੈ। ਜੇ ਲੋਕ ਲਗਾਤਾਰ Save 'ਤੇ ਕਲਿੱਕ ਕਰ ਰਹੇ ਹਨ ਅਤੇ ਅੰਧੇਰੇ ਗਲਤੀਆਂ ਆ ਰਹੀਆਂ ਹਨ, ਤਾਂ ਉਹ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਰਹਿਣਗੇ, ਰਿਫਰੇਸ਼ ਕਰਦੇ ਰਹਿਣਗੇ ਅਤੇ ਟਿਕਟ ਖੋਲ੍ਹਾਂਗੇ। ਸਪਸ਼ਟ ਸੁਨੇਹੇ ਲੋਡ ਕਮ ਅਤੇ ਨਿਰਾਸ਼ਾ ਘਟਾਉਂਦੇ ਹਨ।
ਇਕ ਚੰਗੀ ਪ੍ਰਣਾਲੀ ਇਹ ਹੈ ਕਿ ਐਪ ਦੀ ਸਿਰਲੇਖ 'ਤੇ ਇੱਕ ਦਿੱਖੀ ਅਤੇ ਸਥਾਈ ਬੈਨਰ ਦਿਖਾਓ। ਇਸਨੂੰ ਛੋਟਾ ਅਤੇ ਤੱਥ-ਅਧਾਰਿਤ ਰੱਖੋ: ਕੀ ਹੋ ਰਿਹਾ ਹੈ, ਉਮੀਦ ਕੀ ਰੱਖੋ, ਅਤੇ ਹੁਣ ਕੀ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇਸਨੂੰ ਇੱਕ ਗੁਮ ਹੋ ਜਾਣ ਵਾਲੇ ਟੋਸਟ ਵਿੱਚ ਨਾ ਛੱਡੋ।
ਯੂਜ਼ਰ ਮੁੱਖ ਤੌਰ 'ਤੇ ਇਹ ਜਾਣਨਾ ਚਾਹੁੰਦੇ ਹਨ ਕਿ ਉਹ ਕੰਮ ਜਾਰੀ ਰੱਖ ਸਕਦੇ ਹਨ ਜਾਂ ਨਹੀਂ। ਸਪਸ਼ਟ ਭਾਸ਼ਾ ਵਿੱਚ ਇਹ ਲਿਖੋ। ਜ਼ਿਆਦਾਤਰ ਉਤਪਾਦਾਂ ਲਈ ਇਹ ਮਤਲਬ ਹੁੰਦਾ ਹੈ:
ਇੱਕ ਸਧਾਰਨ ਸਥਿਤੀ ਲੇਬਲ ਭੀ ਲੋਕਾਂ ਨੂੰ ਤਰੱਕੀ ਸਮਝਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਬਿਨਾਂ ਅਨੁਮਾਨ ਲਗਾਉਣ ਦੇ। "Investigating" ਮਤਲਬ ਤੁਸੀਂ ਅਜੇ ਵੀ ਕਾਰਨ ਲੱਭ ਰਹੇ ਹੋ। "Stabilizing" ਮਤਲਬ ਤੁਸੀਂ ਲੋਡ ਘਟਾ ਰਹੇ ਹੋ ਅਤੇ ਡੇਟਾ ਦੀ ਰੱਖਿਆ ਕਰ ਰਹੇ ਹੋ। "Recovering" ਮਤਲਬ ਸੇਵਿਆਂ 'ਤੇ ਲਿਖਤ ਜਲਦੀ ਵਾਪਸ ਆਵੇਗੀ, ਪਰ ਸ਼ਾਇਦ ਧੀਮੀ ਹੋਵੇ।
ਦੋਸ਼ਾਰੋਪਣ ਵਾਲੀ ਜਾਂ ਅਸਪਸ਼ਟ ਭਾਸ਼ਾ ਤੋਂ ਬਚੋ ਜਿਵੇਂ "ਕੁਝ ਗਲਤ ਹੋ ਗਿਆ" ਜਾਂ "ਤੁਹਾਨੂੰ ਅਧਿਕਾਰ ਨਹੀਂ ਸੀ"। ਜੇ ਬਟਨ ਨਿਸ਼ਕ੍ਰਿਯ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਲੇਬਲ ਕਰੋ: "ਇਸ ਸਮੇਂ ਸੰਪਾਦਨ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਰੁਕਿਆ ਹੋਇਆ ਹੈ ਜਦ ਤੱਕ ਅਸੀਂ ਸਿਸਟਮ ਸਥਿਰ ਨਹੀਂ ਕਰ ਲੈਂਦੇ।"
ਇੱਕ ਛੋਟਾ ਉਦਾਹਰਨ: ਇੱਕ CRM ਵਿੱਚ, ਸੰਪਰਕ ਅਤੇ ਡੀਲ ਪੰਨੇ ਪੜ੍ਹਨ-ਯੋਗ ਰਹਿਣ, ਪਰ Edit, Add note, ਅਤੇ New deal ਬਟਨ ਨਿਸ਼ਕ੍ਰਿਯ ਹੋਣ। ਜੇ ਕੋਈ ਫਿਰ ਵੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਛੋਟਾ ਡਾਇਲਾਗ ਦਿਖਾਓ: "ਹਾਲੇ ਤਬਦੀਲੀਆਂ ਰੋਕੀਆਂ ਗਈਆਂ ਹਨ। ਤੁਸੀਂ ਇਸ ਰਿਕਾਰਡ ਦੀ ਨਕਲ ਕਰ ਸਕਦੇ ਹੋ ਜਾਂ ਲਿਸਟ ਐਕਸਪੋਰਟ ਕਰ ਸਕਦੇ ਹੋ, ਫਿਰ ਬਾਅਦ ਵਿੱਚ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰੋ।"
ਜਦੋਂ ਤੁਸੀਂ read-only ਚਾਲੂ ਕਰਦੇ ਹੋ, ਮਕਸਦ "ਹਰ ਚੀਜ਼ ਦਿਖਾਈ ਦੇਵੇ" ਨਹੀਂ ਹੁੰਦਾ। ਮਕਸਦ ਉਹ ਥੋੜ੍ਹੀਆਂ ਪੇਜ਼ਾਂ ਰੱਖਣਾ ਹੈ ਜੋ ਲੋਕਾਂ ਲਈ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹਨ, ਬਿਨਾਂ ਡੇਟਾਬੇਸ 'ਤੇ ਹੋਰ ਦਬਾਅ ਪਾਉਣ ਦੇ।
ਭਾਰੀ ਸਕਰੀਨਾਂ ਨੂੰ ਛਾਂਟੋ। ਲੰਬੀਆਂ ਟੇਬਲਾਂ, ਬਹੁਤ ਸਾਰੇ ਫਿਲਟਰ, ਫ੍ਰੀ-ਟੈਕਸਟ ਖੋਜ ਅਤੇ ਜਟਿਲ ਸੋਰਟ ਆਮ ਤੌਰ 'ਤੇ ਸਲੋ ਕੁਏਰੀਜ਼ ਚਲਾਉਂਦੇ ਹਨ। read-only ਵਿੱਚ ਉਹਨਾਂ ਸਕਰੀਨਾਂ ਨੂੰ ਸਧਾਰਾ ਕਰੋ: ਘੱਟ ਫਿਲਟਰ ਵਿਕਲਪ, ਇੱਕ ਸੁਰੱਖਿਅਤ ਡਿਫਾਲਟ ਸੋਰਟ, ਅਤੇ ਇਕ ਨਿਰਧਾਰਤ ਤਰੀਕੇ ਨਾਲ ਮਿਤੀ ਸੀਮਾ ਕੈਪ ਕਰੋ।
ਜਿਹੜੀਆਂ ਪੰਨੀਆਂ ਮਹੱਤਵਪੂਰਕ ਹਨ, ਉਨ੍ਹਾਂ ਲਈ ਕੈਸ਼ ਕੀਤੇ ਜਾਂ ਪ੍ਰੀਕੰਪਿਊਟ ਕੀਤੇ ਦ੍ਰਿਸ਼ ਵਰਤੋਂ। ਇੱਕ ਸਧਾਰਨ "account overview" ਜੋ ਕੈਸ਼ ਜਾਂ ਸਮਰੀ ਟੇਬਲ ਤੋਂ ਪੜ੍ਹਦਾ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ ਕੱਚੇ ਇਵੈਂਟ ਲੌਗ ਜਾਂ ਕਈ ਟੇਬਲਾਂ ਨੂੰ ਜੋੜਨ ਨਾਲੋਂ ਸੁਰੱਖਿਅਤ ਹੁੰਦਾ ਹੈ।
ਪੜ੍ਹਨੀਆਂ ਨੂੰ ਜਿਊਂਦਾ ਰੱਖਣ ਦੇ ਪ੍ਰਯੋਗ:
একਸAMPLE: ਇੱਕ CRM ਘਟਨਾ ਵਿੱਚ, View contact, View deal status ਅਤੇ View last note ਕੰਮ ਕਰ ਰਹੇ ਹੋਣ। ਅਕਸਰ Advanced search, Revenue chart ਅਤੇ Full email timeline ਨੂੰ ਤਬਕ ਦੀ ਤਰ੍ਹਾਂ ਲੁਕਾ ਦਿਓ ਅਤੇ ਦਰਸਾਓ ਕਿ ਡਾਟਾ ਕੁਝ ਮਿੰਟ ਪੁਰਾਣਾ ਹੋ ਸਕਦਾ ਹੈ।
ਜਦੋਂ ਤੁਸੀਂ read-only ਚਾਲੂ ਕਰਦੇ ਹੋ, ਤਾਂ ਸਭ ਤੋਂ ਵੱਡਾ ਹੈਰਾਨੀ ਅਕਸਰ UI ਨਹੀਂ ਹੁੰਦੀ—ਉਹ ਹਨ ਅਦਿੱਖੇ ਲਿਖਣ ਵਾਲੇ: ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ, ਨਿਯਤ ਸਿੰਕ, ਐਡਮਿਨ ਬਲਕ ਐਕਸ਼ਨ ਅਤੇ ਤੀਸਰੀ-ਪੱਖੀ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਜੋ ਡੇਟਾਬੇਸ 'ਤੇ ਲਗਾਤਾਰ ਲਿਖਦੇ ਰਹਿੰਦੇ ਹਨ।
ਰਿਕਾਰਡ ਬਣਾਉਣ ਜਾਂ ਅਪਡੇਟ ਕਰਨ ਵਾਲੇ ਬੈਕਗ੍ਰਾਊਂਡ ਕੰਮਾਂ ਨੂੰ ਰੋਕੋ। ਆਮ ਗੁਨਾਹਗਾਰ ਹਨ: ਇੰਪੋਰਟ, ਨਾਈਟਲੀ ਸਿੰਕ, ਈਮੇਲ ਭੇਜਣ ਜੋ delivery logs ਲਿਖਦੇ ਹਨ, ਐਨਾਲਿਟਿਕਸ ਰੋਲਅਪ ਅਤੇ retry ਲੂਪ। ਇਹਨਾਂ ਨੂੰ ਰੋਕਣ ਨਾਲ ਤੁਰੰਤ ਦਬਾਅ ਘਟਦਾ ਹੈ ਅਤੇ ਦੂਜੀ ਲਹਿਰ ਦੇ ਲੋਡ ਤੋਂ ਬਚਾਅ ਹੁੰਦਾ ਹੈ।
ਸੁਰੱਖਿਅਤ ਡਿਫਾਲਟ ਇਹ ਹੈ ਕਿ ਲਿਖਤ-ਭਰਪੂਰ ਜੌਬਾਂ ਨੂੰ ਰੋਕੋ ਜਾਂ ਥ੍ਰੋਟਲ ਕਰੋ ਅਤੇ ਕਿਵੇਂ ਵੀ queue consumers ਜੋ ਨਤੀਜੇ ਪERSIST ਕਰਦੇ ਹਨ, ਉਹਨਾਂ ਨੂੰ ਰੋਕੋ, ਐਡਮਿਨ ਬਲਕ ਕਾਰਵਾਈਆਂ ਵਿਸ਼ੇਸ਼ਤ: mass updates, bulk deletes, large re-indexes ਰੋਕੋ, ਅਤੇ ਲਿਖਣ ਵਾਲੇ ਏਂਡਪਾਇੰਟਾਂ 'ਤੇ ਟਾਇਮਆਊਟ ਦੀ ਥਾਂ ਇੱਕ ਸਪਸ਼ਟ ਅਸਥਾਈ ਜਵਾਬ ਦਿਓ।
webhook ਅਤੇ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਲਈ ਸਪਸ਼ਟਤਾ ਉਮੀਦ ਤੋਂ ਵੱਧ ਬਿਹਤਰ ਹੈ। ਜੇ ਤੁਸੀਂ ਇੱਕ webhook ਸੁਵੀਕਾਰ ਕਰ ਲੈਂਦੇ ਹੋ ਪਰ ਉਸਨੂੰ ਪ੍ਰੋਸੈਸ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਅਸੰਗਤੀਆਂ ਪੈਦਾ ਕਰ ਦਿਓਗੇ। ਜਦੋਂ ਲਿਖਤਾਂ ਰੋਕੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਤਾਂ ਭੇਜਣ ਵਾਲੇ ਨੂੰ ਦੱਸਦਿਆਂ ਇੱਕ ਅਸਥਾਈ ਫੇਲ ਰਿਟਰਨ ਕਰੋ ਤਾਂ ਕਿ ਉਹ ਬਾਅਦ ਵਿੱਚ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰਨ।
"ਬਾਅਦ ਲਈ ਕਿਊ" ਕਰਨ ਨਾਲ ਸੰਭਾਵਤ ਬੈਕਲਾਗ ਬਣ ਸਕਦਾ ਹੈ ਜੋ ਜਦੋਂ ਤੁਸੀਂ ਲਿਖਤਾਂ ਵਾਪਸ ਖੋਲ੍ਹਦੇ ਹੋ ਤਾਂ ਸਿਸਟਮ ਉੱਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਲੋਡ ਪਾ ਸਕਦਾ ਹੈ। ਕੇਵਲ ਉਹੀ ਯੂਜ਼ਰ ਲਿਖਤਾਂ ਕਿਊ ਕਰੋ ਜੇ ਤੁਸੀਂ idempotency ਨੂੰ ਯਕੀਨੀ ਬਣਾ ਸਕਦੇ, ਕਿਊ ਆਕਾਰ ਸੀਮਤ ਕਰੋ ਅਤੇ ਯੂਜ਼ਰ ਨੂੰ ਸੱਚੀ ਸਥਿਤੀ (pending vs saved) ਦਿਖਾਓ।
ਅਖੀਰ ਵਿੱਚ, ਆਪਣੇ ਪੇਡੂਚ продукт ਵਿੱਚ ਛੁਪੇ ਬਲਕ ਰਾਇਟਰਾਂ ਦਾ ਆਡੀਟ ਕਰੋ। ਜੇ ਕੋਈ automation ਹਜ਼ਾਰਾਂ ਰੋ ਅਪਡੇਟ ਕਰ ਸਕਦੀ ਹੈ, ਤਾਂ read-only ਵਿੱਚ ਉਹਨੂੰ ਬਲਾਇ ਕੋਠੇ ਬੰਦ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਭਾਵੇਂ ਬਾਕੀ ਐਪ ਚੱਲ ਰਹੀ ਹੋਵੇ।
ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਇੱਕ ਖਰਾਬ ਘਟਨਾ ਨੂੰ ਹੋਰ ਭਿਆਨਕ ਬਣਾਉਣ ਦਾ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ read-only ਮੋਡ ਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਸਜਾਵਟੀ ਬਦਲਾਅ ਸਮਝਿਆ ਜਾਵੇ। ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ UI 'ਤੇ ਬਟਨ ਨਿਸ਼ਕ੍ਰਿਯ ਕਰਦੇ ਹੋ, ਤਾਂ ਲੋਕ APIs, ਪੁਰਾਣੇ ਟੈਬ, ਮੋਬਾਈਲ ਐਪ ਅਤੇ ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ ਰਾਹੀਂ ਲਿਖਦੇ ਰਹਿਣਗੇ। ਡੇਟਾਬੇਸ ਤੇ ਦਬਾਅ ਜਾਰੀ ਰਹੇਗਾ, ਅਤੇ ਯੂਜ਼ਰਾਂ ਦਾ ਭਰੋਸਾ ਵੀ ਖਰਾਬ ਹੋਵੇਗਾ ਕਿਉਂਕਿ ਕੁਝ ਥਾਂ "saved" ਦਿਖੇਗਾ ਅਤੇ ਦੂਜੇ ਥਾਂ ਗੁੰਮ ਹੋਵੇਗਾ।
ਇੱਕ ਅਸਲ read-only ਮੋਡ ਲਈ ਇੱਕ ਸਪਸ਼ਟ ਨਿਯਮ ਚਾਹੀਦਾ ਹੈ: ਸਰਵਰ ਹਰ ਵਾਰੀ ਹਰੇਕ ਕਲਾਇੰਟ ਲਈ ਲਿਖਤਾਂ ਨੂੰ ਇਨਕਾਰ ਕਰੇ।
ਇਹ ਪੈਟਰਨ ਵੀ ਘਟਨਾਵਾਂ ਦੌਰਾਨ ਘਟ-ਘਟ ਆਉਂਦੇ ਹਨ:
ਸਿਸਟਮ ਨੂੰ ਭਰੋਸੇਯੋਗ ਬਣਾਓ। ਇੱਕ ਗਲੋਬਲ ਸਰਵਰ-ਸਾਇਡ ਸਵਿੱਚ ਲਗਾਓ ਜੋ ਲਿਖਤਾਂ ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਜਵਾਬ ਨਾਲ ਰੱਦ ਕਰੇ। ਕੁਲ-ਮਿੰਟ read-only ਵਿੱਚ ਰਹਿਣ ਲਈ ਇੱਕ ਕੁਲਡਾਊਨ ਜੋੜੋ (ਉਦਾਹਰਨ: 10–15 ਮਿੰਟ) ਸਿਵਾਏ ਜਿਸਨੂੰ ਕਿਸੇ ਓਪਰੇਟਰ ਬਦਲਦਾ ਹੋਵੇ।
ਡੇਟਾ ਇੰਟਿਗ੍ਰਿਟੀ 'ਤੇ ਸਖਤੀ ਕਰੋ। ਜੇ ਕੋਈ ਲਿਖਤ ਪੂਰੀ ਤਰ੍ਹਾਂ ਪੂਰੀ ਨਹੀਂ ਹੋ ਸਕਦੀ, ਤਾਂ ਪੂਰੀ ਓਪਰੇਸ਼ਨ ਫੇਲ ਕਰੋ ਅਤੇ ਯੂਜ਼ਰ ਨੂੰ ਦੱਸੋ ਕਿ ਅਗਲਾ ਕਦਮ ਕੀ ਹੈ। ਇੱਕ ਸਧਾਰਨ ਸੁਨੇਹਾ ਜਿਵੇਂ "Read-only mode: viewing works, changes are paused. Try again later." ਦੁਹਰਾਓਟਕ ਕੋਸ਼ਿਸ਼ਾਂ ਘਟਾਉਂਦਾ ਹੈ।
Read-only ਮੋਡ ਸਿਰਫ਼ ਤੇਜ਼ੀ ਨਾਲ ਚਾਲੂ ਹੋਣਾ ਨਹੀਂ ਚਾਹੀਦਾ—ਇਹ ਤਬ ਤਕ ਮਦਦਗਾਰ ਹੈ ਜਦੋਂ ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਚਾਲੂ ਕੀਤਾ ਜਾ ਸਕੇ ਅਤੇ ਹਰ ਜਗ੍ਹਾ ਇਕੋ ਜਿਹਾ ਵਤੀਰਾ ਕਰੇ। ਸਮੱਸਿਆ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਇੱਕ ਸਿੰਗਲ ਟੌਗਲ (ਫੀਚਰ ਫਲੈਗ, ਕਨਫਿਗ, ਐਡਮਿਨ ਸਵਿੱਚ) ਹੈ ਜੋ on-call ਇਕ ਸੀਕੰਡ ਵਿੱਚ ਚਾਲੂ ਕਰ ਸਕੇ, ਬਿਨਾਂ ਡਿਪਲੋਇਮੈਂਟ ਦੇ।
ਜਦੋਂ ਤੁਸੀਂ ਡੇਟਾਬੇਸ ਓਵਰਲੋਡ ਦਾ ਸ਼ੱਕ ਕਰੋ, ਤੇਜ਼ੀ ਨਾਲ ਇੱਕ ਪਾਸ ਕਰੋ ਜੋ ਮੁੱਢਲੇ ਬੁਨਿਆਦੀ ਤੱਥ ਪੁਸ਼ਟੀ ਕਰੇ:
ਘਟਨਾ ਦੌਰਾਨ, ਇਕ ਵਿਅਕਤੀ ਨੂੰ UI ਅਨੁਭਵ ਦੀ ਪੁਸ਼ਟੀ 'ਤੇ ਧਿਆਨ ਦਿਓ, ਸਿਰਫ਼ ਡੈਸ਼ਬੋਰਡਾਂ 'ਤੇ ਨਹੀਂ। ਇੱਕ ਇੰਕੋਗਨਿਟੋ ਖਿੜਕੀ ਵਿੱਚ ਤੇਜ਼ ਸਪੌਟ ਚੈੱਕ ਐਸੋ ਕਿ ਬੈਨਰ ਲੁਕਿਆ ਹੋਇਆ, ਟੁੱਟੇ ਫਾਰਮ ਜਾਂ ਅਨੰਤ ਘੁੰਮਣ ਵਾਲੇ ਸਪੀਨਰ ਆਦਿ ਹਨ ਜਾਂ ਨਹੀਂ—ਇਹ ਗਲਤੀਆਂ ਰਿਫਰੇਸ਼ ਟਰੈਫਿਕ ਵਧਾ ਸਕਦੀਆਂ ਹਨ।
ਇਸਨੂੰ ਚਾਲੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਬਹਾਲੀ ਦੀ ਯੋਜਨਾ ਬਣਾਓ। "ਸਿਹਤਮੰਦ" ਦਾ ਕੀ ਮਤਲਬ ਹੈ (ਲੈਟੈਂਸੀ, ਐਰਰ ਦਰ, ਰੈਪਲਿਕੇਸ਼ਨ ਲੈਗ) ਨਿਰਧਾਰਤ ਕਰੋ ਅਤੇ ਵਾਪਸੀ ਤੋਂ ਬਾਅਦ ਇੱਕ ਛੋਟੀ ਪੁਸ਼ਟੀ ਕਰੋ: ਇੱਕ ਟੈਸਟ ਰਿਕਾਰਡ ਬਣਾਓ, ਸੋਧੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਗਿਣਤੀਆਂ ਅਤੇ ਹਾਲੀਆ ਸਰਗਰਮੀ ਠੀਕ ਹਨ।
ਸਵੇਰੇ 10:20 ਵਜੇ. ਤੁਹਾਡਾ CRM ਢੀਲਾ ਹੈ, ਅਤੇ ਡੇਟਾਬੇਸ CPU pinned ਹੈ। ਸਪੋਰਟ ਟਿਕਟ ਆਉਂਦੀਆਂ ਹਨ: ਯੂਜ਼ਰ ਸੰਪਰਕ ਅਤੇ ਡੀਲ ਸੇਵ ਨਹੀਂ ਕਰ ਪਾ ਰਹੇ। ਪਰ ਟੀਮ ਨੂੰ ਫੋਨ ਕਾਲਾਂ ਤੋਂ ਪਹਿਲਾਂ ਫੋਨ ਨੰਬਰ ਲੱਭਣ, ਡੀਲ ਸਟੇਜ ਦੇਖਣ ਅਤੇ ਆਖਰੀ ਨੋਟ ਪੜ੍ਹਨ ਦੀ ਲੋੜ ਹੈ।
ਤੁਸੀਂ ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ ਚੁਣਦੇ ਹੋ: ਜੋ ਵੀ ਲਿਖਦਾ ਹੈ ਉਹ ਫ੍ਰੀਜ਼ ਕਰ ਦਿਓ, ਸਭ ਤੋਂ ਮੁੱਲਵਾਨ ਪੜ੍ਹਾਈਆਂ ਜਿਊਂਦੀਆਂ ਰੱਖੋ। ਵਿਵਹਾਰਿਕ ਤੌਰ 'ਤੇ, contact search, contact detail pages ਅਤੇ deal pipeline view ਚੱਲਦੇ ਰਹਿਣ। contact ਸੋਧਣਾ, ਨਵੀਂ deal ਬਣਾਉਣਾ, ਨੋਟ ਜੋੜਨਾ ਅਤੇ ਬਲਕ ਇੰਪੋਰਟ ਰੋਕੇ ਜਾਂਦੇ ਹਨ।
UI ਵਿੱਚ ਬਦਲਾਅ ਵਧੀਆ ਅਤੇ ਸ਼ਾਂਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਸੋਧ ਸਕਰੀਨ ਤੇ Save ਬਟਨ ਨਿਸ਼ਕ੍ਰਿਯ ਹੈ ਅਤੇ ਫਾਰਮ ਦਿਖਾਈ ਦੇਂਦਾ ਰਹਿੰਦਾ ਹੈ ਤਾਂ ਕਿ ਲੋਕ ਆਪਣੀ ਟਾਈਪ ਕੀਤੀ ਜਾਣਕਾਰੀ ਨਕਲ ਕਰ ਸਕਣ। ਸਿਰਲੇਖ ਉੱਪਰ ਬੈਨਰ ਦਿਖਾਉਂਦਾ: "Read-only mode is on due to high load. Viewing is available. Changes are paused. Please try again later." ਜੇ ਕੋਈ ਯੂਜ਼ਰ ਫਿਰ ਵੀ ਲਿਖਤ ਟ੍ਰਾਇਗਰ ਕਰਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ API ਕਾਲ), ਤਾਂ ਸਪਸ਼ਟ ਸੁਨੇਹਾ ਵਾਪਸ ਕਰੋ ਅਤੇ ਐਸੀ ਹੋਰ ਆਟੋ-ਰੀਟ੍ਰਾਈਜ਼ ਨਾ ਕੀਤਾ ਜਾਵੇ ਜੋ ਡੇਟਾਬੇਸ 'ਤੇ ਹੋਰ ਹਮਲਾ ਕਰੇ।
ਸੰਚਾਲਨ ਰੂਪ ਵਿੱਚ, ਫਲੋ ਛੋਟਾ ਅਤੇ ਦੁਹਰਾਉਣਯੋਗ ਰੱਖੋ। read-only enable ਕਰੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸਾਰੇ ਲਿਖਣ ਵਾਲੇ ਏਂਡਪਾਇੰਟ ਉਸਨੂੰ ਮੰਨਦੇ ਹਨ। ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ ਜੋ ਲਿਖਦੇ ਹਨ (syncs, imports, email logging, analytics backfills) ਰੋਕੋ। webhook ਅਤੇ ਇੰਟਿਗ੍ਰੇਸ਼ਨਾਂ ਨੂੰ ਥ੍ਰੋਟਲ ਜਾਂ ਰੋਕੋ। ਡੇਟਾਬੇਸ ਲੋਡ, ਐਰਰ ਦਰ ਅਤੇ slow queries ਮਾਨੀਟਰ ਕਰੋ। ਪ੍ਰਭਾਵਤ ਕੀ ਹੈ (ਸੋਧ) ਅਤੇ ਕੀ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ (ਖੋਜ ਅਤੇ ਵੇਖ) ਇਹ ਦੱਸ ਕੇ ਇੱਕ ਸਥਿਤੀ ਅਪਡੇਟ ਪੋਸਟ ਕਰੋ।
ਬਰਾਮਦ ਕ੍ਰਿਆ ਸਿਰਫ਼ ਸਵਿੱਚ ਮੁੜ ਦੇਣਾ ਨਹੀਂ ਹੁੰਦਾ। ਲਿਖਤਾਂ ਨੂੰ ਧੀਰੇ-ਧੀਰੇ ਆਗਿਆ ਦਿਓ, ਅਸਫਲ ਸੇਵਾਂ ਦੀਆਂ ਲੌਗਾਂ ਚੈੱਕ ਕਰੋ, ਅਤੇ queue ਕੀਤੀਆਂ ਨੌਕਰੀਆਂ ਤੋਂ ਹੋ ਸਕਦੀਆਂ write-storms ਤੇ ਨਜ਼ਰ ਰੱਖੋ। ਫਿਰ ਸਪਸ਼ਟ ਸੰਚਾਰ ਕਰੋ: "Read-only mode is off. Saving is restored. If you tried to save between 10:20 and 10:55, please recheck your last changes."
ਘਟਨਾਵਾਂ ਦੌਰਾਨ read-only ਮੋਡ ਸਭ ਤੋਂ ਵਧੀਆ ਤਰ੍ਹਾਂ ਤਦ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਇਹ ਬੋਰੀੰਗ ਅਤੇ ਦੁਹਰਾਉਣਯੋਗ ਹੋ। ਮਕਸਦ ਇੱਕ ਛੋਟੀ ਸਕ੍ਰਿਪਟ ਫੋਲੋ ਕਰਨੀ ਹੈ ਜਿਸਦਾ ਸਪਸ਼ਟ ਮਾਲਕ ਅਤੇ ਚੈੱਕਸ ਹੋਣ।
ਇਸਨੂੰ ਇੱਕ ਪੰਨਾ ਰੱਖੋ। ਆਪਣੇ ਟ੍ਰਿਗਰ (ਕੁਝ ਸਿਗਨਲ ਜੋ read-only ਚਾਲੂ ਕਰਨ ਲਈ ਜਾਇਜ਼ ਹਨ), ਉਹ ਸਵਿੱਚ ਜੋ ਤੁਸੀਂ ਫਲਿਪ ਕਰਦੇ ਹੋ ਅਤੇ ਤੁਸੀਂ ਕਿਵੇਂ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹੋ ਕਿ ਲਿਖਤ ਬਲੌਕ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ, ਕੁਝ ਕੁ ਮੱਖੀ ਪੜ੍ਹਾਈਆਂ ਜੋ ਬੁਰੇ ਦਿਨ 'ਤੇ ਵੀ ਕੰਮ ਕਰਣ, ਸਪਸ਼ਟ ਭੂਮਿਕਾਵਾਂ (ਕੌਣ ਸਵਿੱਚ ਕਰਦਾ ਹੈ, ਕੌਣ ਮੈਟ੍ਰਿਕਸ ਵੇਖਦਾ ਹੈ, ਕੌਣ ਸਪੋਰਟ ਸੰਭਾਲਦਾ ਹੈ) ਅਤੇ exit criteria (ਕੀ ਸੱਚਾਈ ਹੋਣ ਚਾਹੀਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ write ਵਾਪਸ ਆਉਣ) ਸ਼ਾਮਿਲ ਕਰੋ।
ਹੁਣ ਟੈਕਸਟ ਲਿਖੋ ਅਤੇ ਮਨਜ਼ੂਰ ਕਰੋ ਤਾਂ ਕਿ ਔਟੇਜ ਦੌਰਾਨ ਸ਼ਬਦਾਂ 'ਤੇ ਜੰਗ ਨਾ ਹੋਵੇ। ਇੱਕ ਸਧਾਰਨ ਸੈੱਟ ਆਮ ਤੌਰ 'ਤੇ ਜ਼ਿਆਦਾਤਰ ਕੇਸ ਕਵਰ ਕਰਦਾ ਹੈ:
ਸਟੇਜਿੰਗ ਵਿੱਚ ਸਵਿੱਚ ਦਾ ਅਭਿਆਸ ਕਰੋ ਅਤੇ ਸਮਾਂ ਮਾਪੋ। ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਸਪੋਰਟ ਅਤੇ on-call ਨੂੰ ਟੌਗਲ ਮਿਲ ਜਾਵੇ ਤੇ ਲੌਗਸ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਬਲੌਕ ਕੀਤੀਆਂ ਲਿਖਤਾਂ ਦਿਖਾਉਣ۔ ਹਰ ਘਟਨਾ ਤੋਂ ਬਾਅਦ, ਜਿਹੜੀਆਂ ਪੜ੍ਹਨੀਆਂ ਵਾਕਈ ਆਵਸ਼ਕ ਸਨ, ਕਿਹੜੀਆਂ ਨਾਈਸ-ਟੂ-ਹੈਵ ਸਨ, ਅਤੇ ਕਿਹੜੀਆਂ ਗਲਤੀ ਨਾਲ ਲੋਡ ਬਣਾਉਂਦੀਆਂ ਰਹੀਆਂ—ਉਹਨਾਂ ਦੀ ਸਮੀਖਿਆ ਕਰੋ ਅਤੇ ਚੈੱਕਲਿਸਟ ਅਪਡੇਟ ਕਰੋ।
ਜੇ ਤੁਸੀਂ Koder.ai (koder.ai) 'ਤੇ ਉਤਪਾਦ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਹ ਮਦਦਗਾਰ ਹੋ ਸਕਦਾ ਹੈ ਕਿ read-only ਨੂੰ ਆਪਣੇ ਬਣਾਏ ਗਏ ਐਪ ਵਿੱਚ ਪਹਿਲੇ ਦਰਜੇ ਦਾ ਟੌਗਲ ਸਮਝੋ ਤਾਂ ਕਿ UI ਅਤੇ ਸਰਵਰ-ਸਾਈਡ ਲਿਖਣ ਗਾਰਡ ਜਦੋ ਜ਼ਰੂਰ ਹੋਵੇ ਇਕਸਾਰ ਰਹਿਣ।
ਆਮ ਤੌਰ 'ਤੇ ਲਿਖਣ-ਭਰਪੂਰ ਰਸਤੇ ਪਹਿਲਾਂ ਖਰਾਬ ਹੋਂਦੇ ਹਨ: ਸੇਵ, ਸੋਧ, ਚੈਕਆਅਟ, ਇੰਪੋਰਟ ਅਤੇ ਜੋ ਵੀ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਦੀ ਲੋੜ ਰੱਖਦਾ ਹੈ। ਲੋਡ ਹੇਠਾਂ ਲਾਕਸ ਅਤੇ ਧੀਮੇ commits ਲਿਖਤਾਂ ਨੂੰ ਇੱਕ-ਦੂਜੇ ਨੂੰ ਬਲੌਕ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਉਹ ਪੜ੍ਹਨ ਨੂੰ ਵੀ ਧੀਮਾ ਕਰ ਸਕਦੀਆਂ ਹਨ।
ਕਿਉਂਕਿ ਇਹ ਅਣਪ੍ਰਿਡਿਕਟੇਬਲ ਲੱਗਦਾ ਹੈ। ਜੇ ਕਈ ਵਾਰੀ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਕਈ ਵਾਰੀ ਫੇਲ, ਤਾਂ ਯੂਜ਼ਰ ਲਗਾਤਾਰ ਦੁਹਰਾਉਂਦੇ ਹਨ, ਰਿਫਰੇਸ਼ ਕਰਦੇ ਹਨ, ਅਤੇ ਹੋਰ ਲੋਡ ਬਣਾਉਂਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਹੋਰ ਟਾਇਮਆਊਟ ਤੇ ਫਸੇ ਰਿਕੁਏਸਟ ਬਣਦੇ ਹਨ।
ਇਹ ਇੱਕ ਅਸਥਾਈ ਹਾਲਤ ਹੈ ਜਿੱਥੇ ਉਤਪਾਦ ਦੇਖਣ ਲਈ ਉਪਯੋਗੀ ਬਣਿਆ ਰਹਿੰਦਾ ਹੈ ਪਰ ਕਿਸੇ ਵੀ ਤਰ੍ਹਾਂ ਦੀ ਤਬਦੀਲੀ ਨੂੰ ਰੱਦ ਕਰ ਦਿੰਦਾ ਹੈ। ਲੋਕ ਦੇਖ ਸਕਦੇ ਹਨ, ਖੋਜ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਰਿਕਾਰਡ ਖੋਲ੍ਹ ਸਕਦੇ ਹਨ, ਪਰ ਜੋ ਵੀ ਡੇਟਾਬੇਸ ਨੂੰ ਬਣਾਉਂਦਾ/ਬਦਲਦਾ/ਹਟਾਂਦਾ ਹੈ, ਉਹ ਰੋਕ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।
ਆਮ ਨਿਯਮ ਇਹ ਹੈ ਕਿ ਪ੍ਰਾਇਮਰੀ ਡੇਟਾਬੇਸ ਵਿੱਚ ਲਿਖਣ ਵਾਲੀ ਕਿਸੇ ਵੀ ਕਾਰਵਾਈ ਨੂੰ ਬਲੌਕ ਕਰੋ, ਜਿਸ ਵਿੱਚ “ਛੁਪੇ ਹੋਏ ਲਿਖਣ” ਵੀ ਸ਼ਾਮਲ ਹਨ—ਉਦਾਹਰਨ ਵਜੋਂ ਆਡੀਟ ਲੌਗ, last-seen ਟਾਈਮਸਟੈਂਪ, ਜਾਂ ਉਹ ਐਨਾਲਿਟਿਕਸ ਇवੈਂਟ ਜੋ ਮੂਲ ਡੇਟਾਬੇਸ ਵਿੱਚ ਸਟੋਰ ਹੁੰਦੇ ਹਨ। ਜੇ ਇਹ ਕਿਸੇ ਰੋ ਨੂੰ ਬਦਲਦਾ ਹੈ ਜਾਂ ਬਾਅਦ ਵਿੱਚ ਲਿਖੇ ਜਾਣ ਵਾਲੇ ਕੰਮ ਨੂੰ ਐਨਕਿਊ ਕਰਦਾ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਲਿਖਤ ਸਮਝੋ।
ਜਦੋਂ ਤੁਸੀਂ ਵੇਖੋ ਕਿ ਲਿਖਤਾਂ ਗਲੱਬਣ ਲੱਗ ਰਹੀਆਂ ਹਨ: ਟਾਇਮਆਊਟ, p95 ਲੈਟੈਂਸੀ ਦਾ ਉੱਡ, ਲਾਕ ਵੇਟ, ਕਨੈਕਸ਼ਨ ਪੂਲ ਖਤਮ ਹੋਣਾ ਜਾਂ ਇੱਕੋ ਕੁਝ ਸਲੋ ਕੀਵਰੀਜ਼ ਦੀ ਭਰਮਾਰ. ਲੋੜ ਹੈ ਕਿ ਅਸੀਹ ਸਮੇਂ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਸਵਿੱਚ ਕਰੀਏ ਤਾਕਿ retry-ਤੂਫਾਨ ਬਣਨ ਤੋਂ ਰੋਕਿਆ ਜਾ ਸਕੇ।
ਇੱਕ ਗਲੋਬਲ ਟੌਗਲ ਜਿਨ੍ਹਾਂ ਨੂੰ ਸਰਵਰ-ਸਾਇਡ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੋਵੇ—ਸਿਰਫ UI ਤੇ ਨਿਰਭਰ ਨਾ ਰਹੋ। UI Save ਬਟਨ ਨੂੰ ਅਯੋਗ ਕਰੇ, ਪਰ ਹਰ ਇੱਕ ਲਿਖਣ ਵਾਲੀ ਏਂਡਪਾਇੰਟ ਸਰਵਰ 'ਤੇ ਹੀ ਫੇਲ ਫਾਸਟ ਕਰੇ ਅਤੇ ਡੇਟਾਬੇਸ ਨੂੰ ਨਾਂ ਛੂਹੇ।
ਇੱਕ ਦ੍ਰਿਸ਼ਯਮਾਨ, ਟਿਕੀ ਰਹਿਣ ਵਾਲਾ ਬੈਨਰ ਦਿਖਾਓ ਜਿਸ ਵਿੱਚ ਇਹ ਲਿਖਿਆ ਹੋਵੇ ਕਿ ਕੀ ਹੋ ਰਿਹਾ ਹੈ, ਕੀ ਚੱਲਦਾ ਰਹੇਗਾ, ਅਤੇ ਕੀ ਰੋਕਿਆ ਗਿਆ ਹੈ। ਬੈਨਰ ਟੋਸਟ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ ਜੋ ਮਿਟ ਜਾਵੇ। ਅਗਰ ਕਾਰਵਾਈ ਬਲੌਕ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਸਪਸ਼ਟ ਸੁਨੇਹਾ ਦਿਖਾਓ ਤਾਂ ਕਿ ਯੂਜ਼ਰ ਬਾਰ-ਬਾਰ ਕੋਸ਼ਿਸ਼ ਨਾ ਕਰੇ।
ਮੁੱਖ ਪੰਨਿਆਂ ਨੂੰ ਹੀ ਰੱਖੋ ਜੋ ਲੋਕ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਵਰਤਦੇ ਹਨ ਅਤੇ ਜੋ ਭਾਰੀ ਕੁਏਰੀਆਂ ਚਲਾਉਂਦੇ ਹਨ ਉਹਨਾਂ ਨੂੰ ਸਧਾਰਾ ਕਰੋ। ਕੈਸ਼, ਪ੍ਰੀਕੰਪਿਊਟ ਕੀਤੇ ਵੇਖੇ ਜਾਂ ਸਮਰੀ ਟੇਬਲ ਵਰਤਣਾ ਵਧੀਆ ਹੈ। ਛੋਟੀ-ਛੋਟੀ ਪੇਜ ਸਾਈਜ਼, ਡਿਫਾਲਟ ਆਰਡਰ ਅਤੇ ਥੋੜ੍ਹਾ ਸਟੇਲ ਡੇਟਾ ਉੱਤੇ ਵੀ ਗੱਲ ਕਰ ਸਕਦੇ ਹੋ।
ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ, ਨਾਈਟਲੀ ਸਿੰਕ, ਇੰਪੋਰਟ, ਆਦਿ ਜੋ ਰਿਕਾਰਡ ਬਣਾਉਂਦੇ ਜਾਂ ਅਪਡੇਟ ਕਰਦੇ ਹਨ—ਉਹਨਾਂ ਨੂੰ ਰੋਕੋ ਜਾਂ ਥ੍ਰੋਟਲ ਕਰੋ। webhook ਨੂੰ ਸਵੀਕਾਰ ਨਾ ਕਰੋ ਜੇ ਤੁਸੀਂ ਉਸਨੂੰ ਪ੍ਰੋਸੈਸ ਨਹੀਂ ਕਰ ਸਕਦੇ—ਥੈੰਪਰੇਰੀ ਫੇਲ ਰਿਟਰਨ ਕਰੋ ਤਾਂ ਕਿ ਭੇਜਣ ਵਾਲਾ ਬਾਅਦ ਵਿੱਚ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰੇ।
ਸਿਰਫ਼ UI ਵਿੱਚ ਬਟਨ ਨਿਸ਼ਕ੍ਰਿਯ ਕਰਨਾ ਸਭ ਤੋਂ ਵੱਡੀ ਗਲਤੀ ਹੈ—API, ਪੁਰਾਣੇ ਟੈਬ ਜਾਂ ਮੋਬਾਈਲ ਕਲਾਇੰਟ ਲਿਖਦੇ ਰਹਿਣਗੇ। ਹੋਰ ਆਮ ਗਲਤੀਆਂ ਹਨ: ਸੋਚ-ਵਿਚਾਰ ਦੇ ਬਿਨਾਂ ਬਾਰ-ਬਾਰ ਸਵਿੱਚ ਕਰਨਾ (flapping), ਅਸਪਸ਼ਟ ਸੁਨੇਹੇ ਦਿਖਾਉਣਾ ਅਤੇ ਅਧੂਰੀ ਲਿਖਤਾਂ ਨੂੰ ਆਗਿਆ ਦੇਣਾ।