ਅੰਦਾਜ਼ੇ ਲਗਾਉਣਾ ਅਤੇ ਸਮਰੱਥਾ ਦੀ ਯੋਜਨਾ ਬਣਾਉਣਾ — ਸੰਭਾਵਤ ਲੋਡ, ਡੇਟਾ ਵਾਲੀਅਮ, ਅਤੇ ਸਰੋਤਾਂ ਦੀ ਲੋੜ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨਾ — ਸਿਸਟਮ ਡਿਜ਼ਾਈਨ ਦਾ ਇਕ ਮਹੱਤਵਪੂਰਨ ਹਿੱਸਾ ਹੈ। ਮੋਟੇ "back-of-the-envelope" ਕੈਲਕੂਲੇਸ਼ਨ ਡਿਜ਼ਾਈਨ ਦੇ ਫੈਸਲਿਆਂ ਨੂੰ ਸੂਚਿਤ ਕਰਦੇ ਹਨ (ਕਿੰਨਾ ਸਕੇਲ ਕਰਨਾ ਹੈ, ਕੀ ਸਰੋਤ ਚਾਹੀਦੇ ਹਨ) ਅਤੇ ਡਿਜ਼ਾਈਨ ਇੰਟਰਵਿਊ ਵਿਚ ਆਮ ਹਨ।
ਅੰਦਾਜ਼ੇ ਦਾ ਮਹੱਤਵ
Estimating scale informs DESIGN decisions:
→ how many servers? how much storage? what database? do you need sharding/caching?
→ understanding the SCALE (small vs massive) shapes the whole design
→ rough numbers guide whether/how to scale (don't over- or under-engineer)
ਕੀ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣਾ ਹੈ (back-of-the-envelope)
✓ TRAFFIC → users, requests/sec (QPS); read vs write ratio (e.g. 100:1 reads:writes)
→ peak vs average (design for peak); daily active users → requests
✓ STORAGE → data size per item × volume × growth over time → total storage (and growth rate)
✓ BANDWIDTH → data transferred per second (request size × QPS)
✓ MEMORY → cache size needed (e.g. cache the hot 20% of data)
→ rough estimates (order of magnitude) → good enough to inform design
ਉਪਯੋਗੀ ਨੰਬਰ ਅਤੇ ਤਰੀਕਾ
→ Know rough "latency numbers": memory ~ns, SSD ~µs, network/disk ~ms, cross-region ~100ms
→ Round numbers; use powers of 10; estimate, don't seek precision
→ Example: 1M daily users × 10 requests = 10M/day ≈ ~115 req/sec average (× peak factor)
→ derive resource needs from the estimates → justify the architecture
→ CAPACITY PLANNING → provision for expected load + growth + headroom; plan to scale
ਇਹ ਕਿਉਂ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ
ਸਕੇਲ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣਾ ਅਤੇ ਸਮਰੱਥਾ ਦੀ ਯੋਜਨਾ ਬਣਾਉਣਾ ਬਖ਼ਿਆ ਪੱਧਰ ਦਾ ਮੁੱਲਵਾਨ ਗਿਆਨ ਹੈ ਕਿਉਂਕਿ ਅੰਦਾਜ਼ਾ ਸਿਸਟਮ ਡਿਜ਼ਾਈਨ ਦੇ ਫੈਸਲਿਆਂ ਨੂੰ ਸੂਚਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਇਹ ਡਿਜ਼ਾਈਨ ਕੰਮ ਅਤੇ ਇੰਟਰਵਿਊਆਂ ਦਾ ਇਕ ਆਮ ਹਿੱਸਾ ਹੈ, ਇਸ ਲਈ ਇਹ ਇਕ ਮੁਫ਼ੀਦ, ਵਿਹਾਰਕ ਹੁਨਰ ਹੈ।
ਸਕੇਲ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣਾ — ਮੋਟੇ "back-of-the-envelope" ਕੈਲਕੂਲੇਸ਼ਨ ਦੁਆਰਾ ਸੰਭਾਵਤ ਲੋਡ, ਡੇਟਾ ਵਾਲੀਅਮ, ਅਤੇ ਸਰੋਤਾਂ ਦੀ ਲੋੜ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨਾ — ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਸਮਝ ਲੈਣਾ ਕਿ ਸਕੇਲ ਪੂਰੀ ਡਿਜ਼ਾਈਨ ਨੂੰ ਆਕਾਰ ਦਿੰਦਾ ਹੈ: ਇਹ ਜਾਣਨਾ ਕਿ ਇਕ ਸਿਸਟਮ ਹਜ਼ਾਰਾਂ ਜਾਂ ਅਰਬਾਂ ਵਿਚੋਲਿਆਂ ਦੂ ਬੇਨਤੀਆਂ ਹੈਂਡਲ ਕਰਦਾ ਹੈ, ਇਹ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਕਿੰਨਾ ਸਕੇਲ ਕਰਨਾ ਹੈ, ਕੀ ਡੇਟਾਬੇਸ ਵਰਤਨੇ ਹਨ, ਅਤੇ ਕੀ sharding ਅਤੇ caching ਦੀ ਲੋੜ ਹੈ, ਜੋ over-engineering (ਛੋਟੇ ਸਕੇਲ ਲਈ ਅਨਿੱਖੜ ਗੁੰਝਲਤਾ) ਅਤੇ under-engineering (ਇਕ ਡਿਜ਼ਾਈਨ ਜੋ ਅਸਲ ਲੋਡ ਹੈਂਡਲ ਨਹੀਂ ਕਰ ਸਕਦਾ) ਦੋਹਾਂ ਤੋਂ ਬਚਣ ਵਿਚ ਸਹਾਇਤਾ ਕਰਦਾ ਹੈ।
ਕੀ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣਾ ਹੈ ਦੀ ਸਮਝ — traffic (ਯੂਜ਼ਰ, requests/sec, read/write ratios, peak vs average), storage (ਡੇਟਾ ਸਾਈਜ਼ ਅਤੇ ਵਿਕਾਸ), bandwidth, ਅਤੇ memory/cache ਦੀ ਲੋੜ — ਸਿਸਟਮ ਦਾ ਸਾਈਜ਼ ਲਗਾਉਣ ਲਈ ਢਾਂਚੇ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ।
ਤਰੀਕੇ ਦੀ ਸਮਝ — ਮੋਟੇ latency ਨੰਬਰ ਜਾਣਨਾ (memory vs SSD vs network vs cross-region), ਗੋਲ ਨੰਬਰ ਅਤੇ powers of 10 ਵਰਤਨੀ, order-of-magnitude ਅੰਦਾਜ਼ਾ ਲਗਾਉਣਾ ਬਜਾਏ ਸ਼ੁੱਧਤਾ ਲਭ ਦੇ, estimates ਤੋਂ ਸਰੋਤਾਂ ਦੀ ਲੋੜ ਉਤਪੰਨ ਕਰਨੀ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਜਾਇਜ਼ ਠਹਿਰਾਉਣ ਲਈ, ਅਤੇ capacity planning (ਸੰਭਾਵਤ ਲੋਡ ਅਤੇ ਵਿਕਾਸ ਅਤੇ headroom ਲਈ ਪ੍ਰਬੰਧ) — ਮੁਫ਼ੀਦ ਅੰਦਾਜ਼ੇ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਣ ਦੀ ਵਿਹਾਰਕ ਕੁਸ਼ਲਤਾ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ।
ਇਹ system design ਇੰਟਰਵਿਊਆਂ ਵਿਚ ਇਕ ਆਮ, ਅਪੇਖਿਤ ਹੁਨਰ ਹੈ (ਜਿੱਥੇ back-of-the-envelope ਅੰਦਾਜ਼ਾ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਸਕੇਲ ਬਾਰੇ ਤਰਕ ਕਰ ਸਕਦੇ ਹੋ) ਅਤੇ ਅਸਲ ਸਮਰੱਥਾ ਯੋਜਨਾ ਵਿਚ।
ਕਿਉਂਕਿ ਸਕੇਲ ਦਾ ਅੰਦਾਜ਼ਾ ਮੁੱਖ ਡਿਜ਼ਾਈਨ ਫੈਸਲਿਆਂ ਨੂੰ ਸੂਚਿਤ ਕਰਦਾ ਹੈ (ਕਿਵੇਂ ਸਕੇਲ ਕਰਨਾ ਹੈ, ਕੀ ਸਰੋਤ ਚਾਹੀਦੇ ਹਨ, over/under-engineering ਤੋਂ ਬਚਣਾ) ਅਤੇ system design ਕੰਮ ਅਤੇ ਇੰਟਰਵਿਊਆਂ ਦਾ ਇਕ ਆਮ ਹਿੱਸਾ ਹੈ, ਅਤੇ ਕਿਉਂਕਿ ਇਹ ਸਮਝ ਕਿ ਕੀ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣਾ ਹੈ ਅਤੇ ਕਿਵੇਂ (back-of-the-envelope ਕੈਲਕੂਲੇਸ਼ਨ, latency ਨੰਬਰ, capacity planning) ਇਕ ਵਿਹਾਰਕ ਹੁਨਰ ਹੈ, ਸਕੇਲ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣਾ ਅਤੇ ਸਮਰੱਥਾ ਦੀ ਯੋਜਨਾ ਬਣਾਉਣਾ ਬਖ਼ਿਆ ਪੱਧਰ ਦਾ ਮੁੱਲਵਾਨ ਗਿਆਨ ਹੈ — system design ਲਈ ਇਕ ਮੁਫ਼ੀਦ, ਅਪੇਖਿਤ ਹੁਨਰ ਜੋ ਮੋਟੀ ਮਾਤਰਾਤਮਕ ਤਰਕ ਦੁਆਰਾ ਆਰਕੀਟੈਕਚਰ ਫੈਸਲਿਆਂ ਨੂੰ ਸੂਚਿਤ ਕਰਦਾ ਹੈ, ਅਸਲ ਸਮਰੱਥਾ ਯੋਜਨਾ ਅਤੇ ਡਿਜ਼ਾਈਨ ਇੰਟਰਵਿਊਆਂ ਵਿਚ ਆਮ ਹੈ, ਅਤੇ ਸਕੇਲ ਅਤੇ ਸਰੋਤਾਂ ਦੀ ਲੋੜ ਦੇ ਯਥਾਰਥਵਾਦੀ ਅੰਦਾਜ਼ਿਆਂ ਵਿਚ ਡਿਜ਼ਾਈਨ ਨੂੰ ਗ੍ਰਾ਼ੰਡ ਕਰਨ ਦੀ ਯੋਗਤਾ ਪ੍ਰਤਿਬਿੰਬਿਤ ਕਰਦਾ ਹੈ।