04 ਜੂਨ 2025·4 ਮਿੰਟ
ਹੋਰਾਈਜ਼ੋਨਟਲ ਸਕੇਲਿੰਗ ਵਰਟੀਕਲ ਸਕੇਲਿੰਗ ਨਾਲੋਂ ਕਿਉਂ ਜ਼ਿਆਦਾ ਔਖੀ ਹੈ
ਵਰਟੀਕਲ ਸਕੇਲਿੰਗ ਆਮ ਤੌਰ 'ਤੇ ਸਿਰਫ CPU/RAM ਵਧਾਉਣਾ ਹੁੰਦਾ ਹੈ। ਹੋਰਾਈਜ਼ੋਨਟਲ ਸਕੇਲਿੰਗ ਵਿਚ ਕੋਆਰਡੀਨੇਸ਼ਨ, ਪਾਰਟੀਸ਼ਨਿੰਗ, ਕੰਸਿਸਟੈਂਸੀ ਅਤੇ ਵੱਧ ਓਪਰੇਸ਼ਨਲ ਕੰਮ ਲੱਗਦਾ ਹੈ—ਇਸੇ ਲਈ ਇਹ ਔਖਾ ਹੈ।
ਵਰਟੀਕਲ ਸਕੇਲਿੰਗ ਆਮ ਤੌਰ 'ਤੇ ਸਿਰਫ CPU/RAM ਵਧਾਉਣਾ ਹੁੰਦਾ ਹੈ। ਹੋਰਾਈਜ਼ੋਨਟਲ ਸਕੇਲਿੰਗ ਵਿਚ ਕੋਆਰਡੀਨੇਸ਼ਨ, ਪਾਰਟੀਸ਼ਨਿੰਗ, ਕੰਸਿਸਟੈਂਸੀ ਅਤੇ ਵੱਧ ਓਪਰੇਸ਼ਨਲ ਕੰਮ ਲੱਗਦਾ ਹੈ—ਇਸੇ ਲਈ ਇਹ ਔਖਾ ਹੈ।
ਸਕੇਲਿੰਗ ਦਾ ਮਤਲਬ ਹੈ “ਛੰਡੇ ਬਿਨਾ ਹੋਰ ਸੰਭਾਲਨਾ।” ਇਹ “ਹੋਰ” ਹੋ ਸਕਦਾ ਹੈ:
ਜਦੋਂ ਲੋਕ ਸਕੇਲਿੰਗ ਦੀ ਗੱਲ ਕਰਦੇ ਹਨ, ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਇਨ੍ਹਾਂ ਵਿਚੋਂ ਕਿਸੇ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹਨ:
ਇਨਾਂ ਵਿੱਚੋਂ ਬਹੁਤ ਕੁਝ ਇੱਕ ਹੀ ਥੀਮ 'ਤੇ ਆਉਂਦਾ ਹੈ: ਸਕੇਲ ਅੱਪ ਇੱਕ “ਇੱਕ-ਸਿਸਟਮ” ਦਾ ਅਹਿਸਾਸ ਬਰਕਰਾਰ ਰੱਖਦਾ ਹੈ, ਜਦਕਿ ਸਕੇਲ ਆਊਟ ਤੁਹਾਡੇ ਸਿਸਟਮ ਨੂੰ ਕਈ ਸੁਤੰਤਰ ਮਸ਼ੀਨਾਂ ਦੇ ਸਮਹੂ ਬਣਾਉਂਦਾ ਹੈ—ਅਤੇ ਇਹੀ ਸਮਨਵਯ ਹੀ ਮੁਸ਼ਕਿਲੀ ਨੂੰ ਬੜ੍ਹਾ ਦਿੰਦਾ ਹੈ।
ਵਰਟੀਕਲ ਸਕੇਲਿੰਗ ਦਾ ਮਤਲਬ ਇੱਕ ਹੀ ਮਸ਼ੀਨ ਨੂੰ ਮਜ਼ਬੂਤ ਕਰਨਾ ਹੈ। ਆਰਕੀਟੈਕਚਰ ਵਹੀ ਰਹਿੰਦੀ, ਪਰ ਸਰਵਰ (ਜਾਂ VM) ਨੂੰ ਅੱਪਗਰੇਡ ਕੀਤਾ ਜਾਂਦਾ ਹੈ: ਵੱਧ CPU ਕੋਰ, ਵੱਧ RAM, ਤੇਜ਼ ਡਿਸਕ, ਉੱਚ ਨੈੱਟਵਰਕ ਥਰੂਪੁੱਟ।
ਇਸਨੂੰ ਵੱਡੀ ਟਰੱਕ ਖਰੀਦਣ ਵਾਂਗ ਸਮਝੋ: ਇੱਕ ਚਾਲਕ ਅਤੇ ਇੱਕ ਵਾਹਨ ਹੀ ਹੈ, ਪਰ ਇਹ ਜ਼ਿਆਦਾ ਲੋਡ ਢੋ ਸਕਦਾ ਹੈ।
ਹੋਰਾਈਜ਼ੋਨਟਲ ਸਕੇਲਿੰਗ ਦਾ ਮਤਲਬ ਹੋਰ ਮਸ਼ੀਨਾਂ ਜੋੜਨਾ ਅਤੇ ਕੰਮ ਵੰਡਣਾ ਹੁੰਦਾ ਹੈ—ਅਕਸਰ ਲੋਡ ਬੈਲੈਂਸਰ ਪਿੱਛੇ। ਇੱਕ ਵੱਡੇ ਸਰਵਰ ਦੀ ਥਾਂ ਤੁਸੀਂ ਕਈ ਸਰਵਰ ਚਲਾ ਰਹੇ ਹੁੰਦੇ ਹੋ।
ਇਹ ਇਕ ਤੋਂ ਵੱਧ ਟਰੱਕ ਵਰਗਾ ਹੈ: ਤੁਸੀਂ ਕੁੱਲ ਮਿਲਾ ਕੇ ਜ਼ਿਆਦਾ ਸਮਾਨ ਹਿਲਾ ਸਕਦੇ ਹੋ, ਪਰ ਹੁਣ ਸ਼ਡਿਊਲਿੰਗ, ਰੂਟਿੰਗ ਅਤੇ ਕੋਰਡੀਨੇਸ਼ਨ ਦੀ ਚਿੰਤਾ ਵੀ ਹੁੰਦੀ ਹੈ।
ਆਮ ਟ੍ਰਿੱਗਰ:
ਟੀਮ ਪਹਿਲਾਂ ਆਮ ਤੌਰ 'ਤੇ scale up ਕਰਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਤੇਜ਼ ਹੈ (ਬੌਕਸ ਅੱਪਗਰੇਡ ਕਰੋ), ਫਿਰ scale out ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਇੱਕ ਮਸ਼ੀਨ ਸੀਮਿਤ ਹੋ ਜਾਂਦੀ ਹੈ ਜਾਂ ਉਚੀ ਉਪਲਬਧਤਾ ਚਾਹੀਦੀ ਹੁੰਦੀ ਹੈ। ਪੱਕੀ ਆਰਕੀਟੈਕਚਰ ਅਕਸਰ ਦੋਹਾਂ ਮਿਲਾਉਂਦੀ ਹੈ: ਵੱਡੇ ਨੋਡ ਅਤੇ ਵੱਧ ਨੋਡ, ਬੋਤਲਨੇਕ ਦੇ ਅਧਾਰ 'ਤੇ।
ਵਰਟੀਕਲ ਸਕੇਲਿੰਗ ਆਕਰਸ਼ਕ ਹੈ ਕਿਉਂਕਿ ਇਹ ਤੁਹਾਡੇ ਸਿਸਟਮ ਨੂੰ ਇੱਕ ਥਾਂ 'ਤੇ ਰੱਖਦੀ ਹੈ। ਇੱਕ ਨੋਡ ਨਾਲ ਆਮ ਤੌਰ 'ਤੇ ਰੀਮੈਂਬਰੀ ਤੇ ਲੋਕਲ ਸਟੇਟ ਦਾ ਇੱਕ ਸਰੋਤ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਪ੍ਰੋਸੈਸ in-memory cache, job queue, session store (ਜੇ ਸੈਸ਼ਨ ਮੈਮੋਰੀ ਵਿੱਚ ਹਨ) ਅਤੇ ਟੈਂਪ ਫਾਇਲਾਂ ਦਾ ਮਾਲਕ ਹੁੰਦਾ ਹੈ।
ਇੱਕ ਸਰਵਰ 'ਤੇ ਜ਼ਿਆਦਾਤਰ ਆਪਰੇਸ਼ਨ ਸਿੱਧੇ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਇੰਟਰ-ਨੋਡ ਕੋਆਰਡੀਨੇਸ਼ਨ ਘੱਟ ਹੁੰਦੀ:
ਜਦੋਂ ਤੁਸੀਂ scale up ਕਰਦੇ ਹੋ, ਤੁਸੀਂ ਜਾਣੂ ਲੀਵਰ ਖਿੱਚਦੇ ਹੋ: CPU/RAM ਵਧਾਓ, ਤੇਜ਼ ਸਟੋਰੇਜ ਵਰਤੋ, ਇੰਡੈਕਸ ਸੁਧਾਰੋ, ਕ੍ਵੈਰੀاں ਟਿਊਨ ਕਰੋ। ਤੁਹਾਨੂੰ ਡੇਟਾ ਵੰਡਣ ਜਾਂ ਕਈ ਨੋਡਾਂ ਵਿਚ “ਅਗਲਾ ਕੀ ਹੋਵੇ” ਉੱਤੇ ਮੁੜ-ਡਿਜ਼ਾਇਨ ਨਹੀਂ ਕਰਨਾ ਪੈਂਦਾ।
ਵਰਟੀਕਲ ਸਕੇਲਿੰਗ ਮੁਫ਼ਤ ਨਹੀਂ ਹੈ—ਪਰ ਇਹ ਜਟਿਲਤਾ ਨੂੰ ਸੰਗ੍ਰਹਿਤ ਰੱਖਦੀ ਹੈ। ਆਖਿਰਕਾਰ ਤੁਹਾਨੂੰ ਸੀਮਾਵਾਂ ਮਿਲਦੀਆਂ ਹਨ: ਜਿਸ ਸਭ ਤੋਂ ਵੱਡੇ ਇੰਸਟੈਂਸ ਨੂੰ ਤੁਸੀਂ ਕਿਰਾਏ 'ਤੇ ਲੈ ਸਕਦੇ ਹੋ, ਘਟਦੀ ਲੋਭਦਾਇਕ ਲਾਭ, ਜਾਂ ਉੱਚ ਖ਼ਰਚ। ਇੱਕ ਵੱਡੀ ਮਸ਼ੀਨ ਨਿਗਰਾਨੀ/ਮੇਟੇਨੈਂਸ ਲਈ ਡਾਊਨਟਾਈਮ ਜੋਖਮ ਵੀ ਵਧਾ ਸਕਦੀ ਹੈ ਜੇ ਤੁਸੀਂ redundancy ਨਹੀਂ ਜੋੜੀ।
ਜਦੋਂ ਤੁਸੀਂ scale out ਕਰਦੇ ਹੋ, ਤੁਸੀਂ ਸਿਰਫ਼ “ਜ਼ਿਆਦਾ ਸਰਵਰ” ਨਹੀਂ ਪਾਉਂਦੇ। ਤੁਸੀਂ ਹੋਰ ਸੁਤੰਤਰ ਕਿਰਦਾਰ ਪਾਉਂਦੇ ਹੋ ਜੋ ਇਹ ਫੈਸਲਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਨੋਡ ਕਿਸ ਕੰਮ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ, ਕਦੋਂ ਅਤੇ ਕਿਹੜੇ ਡੇਟਾ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ।
ਇੱਕ ਮਸ਼ੀਨ ਨਾਲ ਕੋਆਰਡੀਨੇਸ਼ਨ ਅਕਸਰ ਨਿਰਦੇਸ਼ਤ ਨਹੀਂ ਹੁੰਦੀ: ਇੱਕ ਮੈਮੋਰੀ ਸਪੇਸ, ਇੱਕ ਪ੍ਰੋਸੈਸ, ਇੱਕ ਸਥਾਨ। ਕਈ ਮਸ਼ੀਨਾਂ ਨਾਲ, ਕੋਆਰਡੀਨੇਸ਼ਨ ਇੱਕ ਫੀਚਰ ਬਣ ਜਾਂਦੀ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਡਿਜ਼ਾਇਨ ਕਰਨੀ ਪੈਂਦੀ ਹੈ।
ਆਮ ਟੂਲ ਅਤੇ ਪੈਟਰਨ:
ਕੋਆਰਡੀਨੇਸ਼ਨ ਬੱਗ ਆਮ ਤੌਰ 'ਤੇ ਸਾਫ਼ क्रੈਸ਼ ਵਰਗੇ ਨਹੀਂ ਹੁੰਦੇ। ਜ਼ਿਆਦातर ਤੁਸੀਂ ਵੇਖਦੇ ਹੋ:
ਇਹ ਮੁੱਦੇ ਅਕਸਰ ਸਿਰਫ਼ ਅਸਲ ਲੋਡ ਹੇਠ, ਡਿਪਲੋਇਮੈਂਟਾਂ ਦੌਰਾਨ, ਜਾਂ ਜਦੋਂ ਅੰਸ਼ਿਕ ਫੇਲਅਰ ਹੁੰਦਾ ਹੈ, ਵੇਖਣ ਨੂੰ ਮਿਲਦੇ ਹਨ। ਸਿਸਟਮ ਠੀਕ ਲੱਗਦਾ ਹੈ—ਜਦ ਤੱਕ ਦਬਾਅ ਨਹੀਂ ਆਉਂਦਾ।
ਜਦੋਂ ਤੁਸੀਂ scale out ਕਰਦੇ ਹੋ, ਤੁਸੀਂ ਅਕਸਰ ਸਾਰਾ ਡੇਟਾ ਇਕ ਥਾਂ ਨਹੀਂ ਰੱਖ ਸਕਦੇ। ਤੁਸੀਂ ਇਸਨੂੰ ਮਸ਼ੀਨਾਂ ਵਿੱਚ ਵੰਡਦੇ ਹੋ (ਸ਼ਾਰਡ) ਤਾਂ ਜੋ ਬਹੁਤ ਸਾਰੇ ਨੋਡ ਪੈਰਲਲ ਵਿੱਚ ਸੇਵਾ ਦੇ ਸਕਣ। ਇਹ ਵੰਡ ਹੀ ਮੁਸ਼ਕਲੀਆਂ ਦਾ ਸਿਰੋਤ ਬਣਦੀ ਹੈ: ਹਰ ਰੀਡ/ਰਾਈਟ ਤੇ ਇਹ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ “ਕਿਹੜਾ ਸ਼ਾਰਡ ਇਹ ਰਿਕਾਰਡ ਰੱਖਦਾ ਹੈ?”
ਰੇਂਜ ਪਾਰਟੀਸ਼ਨਿੰਗ ਡੇਟਾ ਨੂੰ ਇੱਕ ਕ੍ਰਮਵਾਰ ਕੀ ਦੇ ਆਧਾਰ ਤੇ ਗਰੁੱਪ ਕਰਦੀ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ਯੂਜ਼ਰ A–F ਸ਼ਾਰਡ 1 ਤੇ, G–M ਸ਼ਾਰਡ 2 ਤੇ)। ਇਹ ਸਮਝਣ ਵਿੱਚ ਆਸਾਨ ਹੈ ਤੇ ਰੇਂਜ ਕ્વੈਰੀਆਂ ਲਈ ਵਧੀਆ ਹੈ। ਘਾਟ ਇਹ ਹੈ ਕਿ ਲੋਡ ਅਨਸਮਾਨ ਹੋ ਸਕਦਾ ਹੈ: ਜੇ ਇੱਕ ਰੇਂਜ ਪਾਪੁਲਰ ਹੋ ਜਾਵੇ ਤਾਂ ਉਹ ਸ਼ਾਰਡ ਬੋਤਲਨੇਕ ਬਣ ਜਾਂਦਾ ਹੈ।
ਹੈਸ਼ ਪਾਰਟੀਸ਼ਨਿੰਗ ਇੱਕ ਕੀ ਨੂੰ ਹੈਸ਼ ਕਰਦੀ ਹੈ ਅਤੇ ਨਤੀਜਿਆਂ ਨੂੰ ਸ਼ਾਰਡਾਂ 'ਤੇ ਵੰਡ ਦਿੰਦੀ ਹੈ। ਇਹ ਟ੍ਰੈਫਿਕ ਨੂੰ ਅੱਧਿਕਤਮ ਤੌਰ 'ਤੇ ਸਮਾਨ ਤਰ੍ਹਾਂ ਫੈਲਾਂਦੀ ਹੈ, ਪਰ ਰੇਂਜ ਕਵੈਰੀਆਂ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਸੰਬੰਧਿਤ ਰਿਕਾਰਡ ਬਿਖਰੇ ਹੋ ਜਾਂਦੇ ਹਨ।
ਨੋਡ ਸ਼ਾਮਲ ਕਰੋ ਅਤੇ ਤੁਸੀਂ ਉਸਨੂੰ ਵਰਤਣਾ ਚਾਹੁੰਦੇ ਹੋ—ਅਰਥਾਤ ਕੁਝ ਡੇਟਾ ਖਿਸਕਣਾ ਪੈਂਦਾ ਹੈ। ਨੋਡ ਹਟਾਉ (ਯੋਜਨਾਬੱਧ ਜਾਂ ਫੇਲ) ਅਤੇ ਹੋਰ ਸ਼ਾਰਡਾਂ ਨੂੰ ਕਵਰ ਕਰਨਾ ਪਏਗਾ। ਰੀਬੈਲੈਂਸਿੰਗ ਵੱਡੇ ਟ੍ਰਾਂਸਫਰ, ਕੈਸ਼ ਵਾਰਮ-ਅਪ, ਅਤੇ ਅਸਥਾਈ ਪਰਫਾਰਮੈਂਸ ਘਟਾਉਂਦੀਆਂ ਲਿਆ ਸਕਦੀ ਹੈ। ਮੂਵ ਦੌਰਾਨ ਤੁਹਾਨੂੰ ਸਟੇਲ ਰੀਡ ਅਤੇ ਗਲਤ ਰਾਹਤ ਵਾਲੀਆਂ ਰਾਈਟਸ ਨੂੰ ਰੋਕਣਾ ਪੈਂਦਾ ਹੈ।
ਹੈਸ਼ ਦੇ ਬਾਵਜੂਦ, ਅਸਲੀ ਟ੍ਰੈਫਿਕ ਇਕਸਾਰ ਨਹੀਂ ਹੁੰਦਾ। ਕਿਸੇ ਸੇਲਿਬ੍ਰਿਟੀ ਖਾਤੇ, ਲੋਕਪ੍ਰਿਯ ਪ੍ਰੋਡਕਟ ਜਾਂ ਸਮੇਂ-ਅਧਾਰਿਤ ਪਹੁੰਚ ਪੈਟਰਨ ਇੱਕ ਸ਼ਾਰਡ 'ਤੇ ਲੋਡ ਗਠਾ ਸਕਦੇ ਹਨ। ਇੱਕ ਹਾਟ ਸ਼ਾਰਡ ਸਾਰੇ ਸਿਸਟਮ ਦੀ ਥਰੂਪੁੱਟ ਨੂੰ ਸੀਮਿਤ ਕਰ ਸਕਦਾ ਹੈ।
ਸ਼ਾਰਡਿੰਗ ਲਗਾਤਾਰ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਲਿਆਉਂਦੀ ਹੈ: ਰਾਊਟਿੰਗ ਨਿਯਮਾਂ ਰੱਖਣਾ, ਮਾਈਗ੍ਰੇਸ਼ਨ ਚਲਾਉਣਾ, ਸਕੀਮਾ ਬਦਲਣ 'ਤੋਂ ਬਾਅਦ ਬੈਕਫਿਲ ਕਰਨਾ, ਅਤੇ ਕਲਾਇੈਂਟਾਂ ਨੂੰ ਟੁੱਟਣ ਤੋਂ ਬਿਨਾਂ ਸਪਲਿਟ/ਮਰਜ ਯੋਜਨਾ ਬਣਾਉਣ।
ਜਦੋਂ ਤੁਸੀਂ scale out ਕਰਦੇ ਹੋ, ਤੁਸੀਂ ਸਿਰਫ਼ ਹੋਰ ਸਰਵਰ ਨਹੀਂ ਜੋੜਦੇ—ਤੁਸੀਂ ਆਪਣੀ ਐਪ ਦੀਆਂ ਹੋਰ ਨਕਲਾਂ ਜੋੜਦੇ ਹੋ। ਮੁਸ਼ਕਲ ਪਾਸਾ ਹੈ ਸਟੇਟ: ਕੁਝ ਵੀ ਜੋ ਤੁਹਾਡੀ ਐਪ 'ਰਿਕਾਲ' ਕਰਦੀ ਹੈ ਬੀਚ-ਬੀਚ ਵਿੱਚ ਜਾਂ ਕੰਮ ਦੌਰਾਨ।
ਜੇ ਇੱਕ ਯੂਜ਼ਰ ਸਰਵਰ A 'ਤੇ ਲੌਗਿਨ ਕਰਦਾ ਹੈ ਪਰ ਉਨ੍ਹਾਂ ਦੀ ਅਗਲੀ ਰੀਕਵੇਸਟ ਸਰਵਰ B ਤੇ ਜਾਂਦੀ ਹੈ, ਤਾਂ B ਨੂੰ ਕੀ ਪਤਾ ਹੈ ਕਿ ਉਹ ਕੋਣ ਹੈ?
ਕੈਸ਼ ਚੀਜ਼ਾਂ ਨੂੰ ਤੇਜ਼ ਕਰਦੇ ਹਨ, ਪਰ ਕਈ ਸਰਵਰਾਂ ਦਾ ਮਤਲਬ ਕਈ ਕੈਸ਼ਾਂ। ਹੁਣ ਤੁਸੀਂ ਨਿਪਟਦੇ ਹੋ:
ਕਈ ਵਰਕਰਾਂ ਨਾਲ, ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ ਦੋ ਵਾਰੀ ਚੱਲ ਸਕਦੇ ਹਨ ਜਦ ਤੱਕ ਤੁਸੀਂ ਇਸ ਲਈ ਡਿਜ਼ਾਇਨ ਨਹੀਂ ਕਰਦੇ। ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਨੂੰ ਕਿਉਂਕਿ queue, ਲੀਜ਼/ਲੌਕ, ਜਾਂ idempotent ਨੌਕਰੀ ਲਾਜ਼ਮੀ ਹੁੰਦੀ ਹੈ ਤਾਂ ਕਿ “ਇਨਵਾਇਸ ਭੇਜੋ” ਜਾਂ “ਕਾਰਡ ਚਾਰਜ ਕਰੋ” ਵਾਰੀ ਵਾਰੀ ਨਾ ਹੋਵੇ—ਖਾਸ ਕਰਕੇ retries ਅਤੇ ਰੀਸਟਾਰਟ ਦੌਰਾਨ।
ਇੱਕ ਹੀ ਨੋਡ (ਜਾਂ ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਡੀਬੀ) ਨਾਲ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਸਪਸ਼ਟ “ਸਚਾਈ ਦਾ ਸਰੋਤ” ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ scale out ਕਰਦੇ ਹੋ, ਡੇਟਾ ਅਤੇ ਰੀਕਵੇਸਟ ਕਈ ਮਸ਼ੀਨਾਂ ਵਿਚ ਫੈਲ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਹਰ ਕੋਈ ਸਿੰਕ ਰਹਿਣਾ ਇੱਕ ਲਗਾਤਾਰ ਚਿੰਤਾ ਬਣਦੀ ਹੈ।
ਆਖ਼ਰੀ ਅਣੁਕੂਲਤਾ ਅਕਸਰ ਤੇਜ਼ ਅਤੇ ਸਸਤੀ ਹੁੰਦੀ ਹੈ ਵੱਡੇ ਪੱਧਰ 'ਤੇ, ਪਰ ਇਹ ਹੈਰਾਨ ਕਰਨ ਵਾਲੇ ਐਜ ਕੇਸ ਲਿਆ ਸਕਦੀ ਹੈ।
ਆਮ ਮੁੱਦੇ:
ਤੁਸੀਂ ਫੇਲਿਅਰਾਂ ਨੂੰ ਖ਼ਤਮ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਪਰ ਤੁਸੀਂ ਉਹਨਾਂ ਲਈ ਡਿਜ਼ਾਇਨ ਕਰ ਸਕਦੇ ਹੋ:
ਸਰਵਿਸਾਂ ਦੇ ਦਰਮਿਆਨ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ (order + inventory + payment) ਚਾਹੀਦਾ ਹੈ ਕਿ ਕਈ ਸਿਸਟਮ ਸਹਿਮਤ ਹੋਣ। ਜੇ ਇੱਕ ਕਦਮ ਅੱਧ ਰਾਹ 'ਤੇ ਫੇਲ ਹੋ ਜਾਵੇ, ਤਾਂ ਤੁਹਾਨੂੰ ਮੁਆਵਜਾ ਕਾਰਵਾਈਆਂ ਅਤੇ ਨਜ਼ਦੀਕੀ ਲੇਖਾ-ਰਖਾ ਦੀ ਲੋੜ ਪੈਂਦੀ ਹੈ। ਨੈੱਟਵਰਕ ਅਤੇ ਨੋਡਾਂ ਦੇ ਅਲੱਗ-ਅਲੱਗ ਫੇਲ ਹੋਣ 'ਤੇ
Vertical scaling means making a single machine bigger (more CPU/RAM/faster disk). Horizontal scaling means adding more machines and spreading work across them.
Vertical often feels simpler because your app still behaves like “one system,” while horizontal requires multiple systems to coordinate and stay consistent.
Because the moment you have multiple nodes, you need explicit coordination:
A single machine avoids many of these distributed-system problems by default.
It’s the time and logic spent making multiple machines behave like one:
Even if each node is simple, the system behavior gets harder to reason about under load and failure.
Sharding (partitioning) splits data across nodes so no single machine has to store/serve everything. It’s hard because you must:
It also increases operational work (migrations, backfills, shard maps).
State is anything your app “remembers” between requests or while work is in progress (sessions, in-memory caches, temporary files, job progress).
With horizontal scaling, requests may land on different servers, so you typically need shared state (e.g., Redis/db) or you accept trade-offs like sticky sessions.
If multiple workers can pick up the same job (or a job is retried), you can end up charging twice or sending duplicate emails.
Common mitigations:
Strong consistency means once a write succeeds, all readers immediately see it. Eventual consistency means updates propagate over time, so some readers may see stale data briefly.
Use strong consistency for correctness-critical data (payments, balances, inventory). Use eventual consistency where small delays are acceptable (analytics, recommendations).
In a distributed system, calls become network calls, which adds latency, jitter, and failure modes.
Basics that usually matter most:
Partial failure means some components are broken or slow while others are fine. The system can be “up” but still produce errors, timeouts, or inconsistent behavior.
Design responses include replication, quorums, multi-zone deployments, circuit breakers, and graceful degradation so failures don’t cascade.
Across many machines, evidence is fragmented: logs, metrics, and traces live on different nodes.
Practical steps: