ਸਾਫਟਵੇਅਰ ਇੰਜੀਨੀਅਰਇੰਟਰਵਿਊ ਜਵਾਬ

ਮੇਰਾ ਪਹੁੰਚ ਇਕ ਢਾਂਚਾਬੱਧ ਫਰੇਮਵਰਕ ਦੀ ਤਰ੍ਹਾਂ ਹੈ ਜੋ ਮੈਂ ਇੰਜੀਨੀਅਰਿੰਗ ਵਿੱਚ ਸਾਲਾਂ ਦੀ ਕੰਮ ਕਰਨ ਦੀ ਤਜਰਬੇ ਨਾਲ ਸੁਧਾਰਿਆ ਹੈ। Step 1 — ਕੋਡ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਸਪਸ਼ਟੀਕਰਣ। ਮੈਂ ਪੂਰੇ ਸਕੋਪ ਨੂੰ ਸਮਝਣ ਲਈ ਸਵਾਲ ਪੁੱਛਦਾ/ਦੀ ਹਾਂ: ਪਾਬੰਦੀਆਂ, ਸਕੇਲ ਦੀ ਲੋੜ, ਸਫਲਤਾ ਮਾਪਦੰਡ, ਅਤੇ ਐਜ ਕੇਸ। ਇੱਕ ਠੀਕ ਤਰ੍ਹਾਂ ਨਾ ਸਮਝੀ ਜਾਣ ਵਾਲੀ ਸਮੱਸਿਆ ਗਲਤ ਚੀਜ਼ ਲਈ ਸੁੰਦਰ ਹੱਲਾਂ ਵਜੋਂ ਖਤਮ ਹੋ ਸਕਦੀ ਹੈ। ਜਿਵੇਂ ਹੀ ਮੈਨੂੰ ਸਪਸ਼ਟੀਕਰਣ ਮਿਲਦੀ ਹੈ, ਮੈਂ: - ਸਮੱਸਿਆ ਨੂੰ ਛੋਟੇ, ਸਵਤੰਤਰ ਤੌਰ ਤੇ ਹੱਲਯੋਗ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡਦਾ/ਦੀ ਹਾਂ - ਮੌਜੂਦਾ ਪੈਟਰਨ, ਲਾਇਬ੍ਰੇਰੀਆਂ, ਜਾਂ ਪ੍ਰੇਸੀਡੈਂਟ ਦੀ ਪਛਾਣ ਕਰਦਾ/ਦੀ ਹਾਂ ਜੋ ਲਾਗੂ ਹੋ ਸਕਦੇ ਹਨ - ਕਿਸੇ ਵੀ ਕੋਡ ਤੋਂ ਪਹਿਲਾਂ ਕਾਗਜ਼ ਜਾਂ ਵਾਈਟਬੋਰਡ 'ਤੇ ਉੱਚ-ਸਤਹ ਡਿਜ਼ਾਈਨ ਦਾ ਖਾਕਾ ਬਣਾਉਂਦਾ/ਦੀ ਹਾਂ - ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਤਰਕ ਨੂੰ ਤਸਦੀਕ ਕਰਨ ਲਈ ਪੈਨਸੂਡੋ ਕੋਡ ਲਿਖਦਾ/ਦੀ ਹਾਂ - ਹਰੇਕ ਕਦਮ 'ਤੇ ਟੈਸਟ ਚਲਾ ਕੇ ਕ੍ਰਮਵੱਧ ਤਰੀਕੇ ਨਾਲ ਲਾਗੂ ਕਰਦਾ/ਦੀ ਹਾਂ ਵਾਸਤਵਿਕ ਉਦਾਹਰਣ: ਜਦੋਂ ਮੈਨੂੰ ਸਾਡੇ API ਦੀ ਰਿਸਪਾਂਸ ਟਾਈਮ 2.4 seconds ਤੋਂ ਘੱਟ ਅਤੇ 500ms ਤੋਂ ਘੱਟ ਕਰਨ ਦਾ ਟਾਸਕ ਦਿੱਤਾ ਗਿਆ, ਮੈਂ ਤੁਰੰਤ ਅਪਟੀਮਾਈਜ਼ ਨਹੀਂ ਕੀਤਾ। ਪਹਿਲਾਂ ਮੈਂ ਪੂਰੇ ਰਿਕਵੇਸਟ ਲਾਈਫਸਾਇਕਲ ਨੂੰ ਪ੍ਰੋਫ਼ਾਈਲ ਕੀਤਾ ਤੇ ਪਤਾ ਲੱਗਿਆ ਕਿ 80% ਲੇਟੈਂਸੀ ਤਿੰਨ N+1 ਡੇਟਾਬੇਸ ਕਵੇਰੀਆਂ ਤੋਂ ਆ ਰਹੀ ਸੀ। ਕੇਵਲ ਉਹਨਾਂ ਨੂੰ ਠੀਕ ਕਰਨ ਨਾਲ ਰਿਸਪਾਂਸ ਟਾਈਮ 340ms ਤੇ ਆ ਗਿਆ — ਬਿਨਾਂ ਐਪਲੀਕੇਸ਼ਨ ਲੇਅਰ ਨੂੰ ਛੂਹੇ। ਮੇਰਾ ਨਿਯਮ: ਚੰਗੀ ਸਾਫਟਵੇਅਰ ਇੰਜੀਨੀਅਰਿੰਗ 60% ਸੋਚਣਾ ਅਤੇ 40% ਟਾਈਪਿੰਗ ਹੈ। ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਤੋਂ ਬਾਅਦ, ਮੈਂ ਮੂਲ ਜ਼ਰੂਰਤਾਂ ਦੇ ਖਿਲਾਫ ਵੈਰੀਫਾਈ ਕਰਦਾ/ਦੀ ਹਾਂ, ਪੀਅਰ ਰਿਵਿਊ ਕਰਵਾਉਂਦਾ/ਦੀ ਹਾਂ, ਅਤੇ ਟੀਮ ਲਈ ਮੁੱਖ ਫੈਸਲਿਆਂ ਨੂੰ ਡੌਕਯੂਮੈਂਟ ਕਰਦਾ/ਦੀ ਹਾਂ। ਜਟਿਲ ਸਮੱਸਿਆਵਾਂ ਸਿੱਖਣ ਦੇ ਮੌਕੇ ਵੀ ਹੁੰਦੀਆਂ ਹਨ — ਮੈਂ ਛੋਟੀ-ਝੋਟੀ ਪੋਸਟ-ਮੋਰਟਮ ਲਿਖਦਾ/ਦੀ ਹਾਂ ਤਾਂ ਜੋ ਅਗਲੀ ਵਾਰੀ ਮੈਂ ਕੀ ਵੱਖਰਾ ਕਰਾਂਗਾ ਇਹ ਦਰਜ ਰਹੇ।

ਟੀਮ ਵਿੱਚ ਕੋਡ ਗੁਣਵੱਤਾ ਇੱਕ ਪ੍ਰਣਾਲੀगत ਚੁਣੌਤੀ ਹੈ, ਸਿਰਫ ਨਿੱਜੀ ਨਹੀਂ। ਮੇਰਾ ਪਹੁੰਚ ਤਿੰਨ ਪੱਧਰਾਂ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ: ਪ੍ਰਕਿਰਿਆ, ਟੂਲਿੰਗ, ਅਤੇ ਸੰਸਕ੍ਰਿਤੀ। ਪ੍ਰਕਿਰਿਆ: - ਹਰ ਪਲ ਰਿਕਵੈਸਟ ਲਈ ਜ਼ਰੂਰੀ ਪੀਅਰ ਰਿਵਿਊ — ਕੋਈ ਛੂਟ ਨਹੀਂ, ਭਾਵੇਂ ਸੀਨੀਅਰ ਇੰਜੀਨੀਅਰ ਹੋਵੇ - ਰਿਵਿਊਜ਼ ਵਿਸ਼ੇਸ਼ ਅਤੇ ਨਿਰਮਾਣਾਤਮਕ ਹੋਣ — ਸਿਰਫ ਠੀਕ-ਠਰਾਉ ਨਹੀਂ: "ਇਹ ਲੂਪ O(n²) ਹੈ — ਇੱਥੇ ਕਿਵੇਂ O(n) ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ" - ਜਿੱਥੇ ਉਚਿਤ ਹੋਵੈ ਟੈਸਟ-ਡ੍ਰਿਵਨ ਡਿਵੈਲਪਮੈਂਟ; ਘੱਟੋ-ਘੱਟ, ਟੈਸਟ ਕੋਡ ਨਾਲੋਂ ਨਾਲ ਲਿਖੇ ਜਾਣ — ਬਾਦ ਵਿੱਚ ਨਹੀਂ - ਉਤਪੱਤੀ ਘਟਨਾ ਸਮੀਖਿਆਵਾਂ (post-incident reviews) ਤਾਂ ਜੋ ਪ੍ਰੋਡਕਸ਼ਨ 'ਚ ਕੁਝ ਟੁੱਟਣ 'ਤੇ ਸਾਂਝੀ ਜਾਣਕਾਰੀ ਬਣੇ ਟੂਲਿੰਗ: - Linters (ESLint, Pylint) ਅਤੇ formatters (Prettier, Black) CI ਵਿੱਚ ਲਾਗੂ — ਸਟਾਈਲ ਬਹਿਸ ਰਾਤੋਂ-ਰਾਤ ਗਾਇਬ - ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਸਟੈਟਿਕ ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ ਸੁਰੱਖਿਆ ਸਕੈਨਿੰਗ (SonarQube, Snyk) - ਕੋਵਰੇਜ ਥ੍ਰੈਸ਼ਹੋਲਡ ਜਿਹੜੇ ਯੂਨਿਟ ਟੈਸਟ ਕੋਵਰੇਜ ਨਿਰਧਾਰਿਤ ਘੱਟੋ-ਘੱਟ ਤੋਂ ਹੇਠਾਂ ਆਵੇ ਤਾਂ ਬਿਲਡ ਫੇਲ ਕਰਾਉਂਦੇ ਹਨ ਵਾਸਤਵਿਕ ਉਦਾਹਰਣ: ਮੇਰੇ ਪਿਛਲੇ ਕੰਪਨੀ ਵਿੱਚ, ਸਾਡੇ ਕੋਲ 23% ਬਗ-ਇਨ-ਪ੍ਰੋਡਕਸ਼ਨ ਦਰ ਸੀ। ਮੈਂ ਜ਼ਰੂਰੀ PR ਰਿਵਿਊਜ਼ ਇੱਕ ਰਿਵਿਊ ਚੈਕਲਿਸਟ ਦੇ ਨਾਲ ਲਿਆਇਆ, ESLint ਅਤੇ pre-commit hook ਜੋੜਿਆ, ਅਤੇ ਟੈਸਟ ਲਿਖਣ ਬਾਰੇ ਇੱਕ ਸੈਸ਼ਨ ਚਲਾਇਆ। ਦੋ ਸਪ੍ਰਿੰਟਾਂ ਵਿੱਚ, ਸਾਡੀ ਬਗ ਦਰ 7% ਤੱਕ ਘੱਟ ਹੋ ਗਈ ਅਤੇ ਡਿਪਲੋਇ ਫ੍ਰਿਕਵੈਂਸੀ ਵਧ ਗਈ। ਸੰਸਕ੍ਰਿਤੀ ਵਾਲਾ ਹਿੱਸਾ ਬਰਾਬਰ ਜ਼ਰੂਰੀ ਹੈ — ਮੈਂ ਕੋਡ ਰਿਵਿਊ ਨੂੰ ਨਿਰਾਸ਼ਨਾ ਵਜੋਂ ਨਹੀਂ, ਮਾਰਗਦਰਸ਼ਨ ਵਜੋਂ ਫ੍ਰੇਮ ਕਰਦਾ/ਦੀ ਹਾਂ, ਜਿਸ ਨਾਲ ਇੰਜੀਨੀਅਰ ਖੁਲ੍ਹੇ ਦਿਲ ਨਾਲ ਸੁਣਦੇ ਹਨ ਨਾ ਕਿ ਰक्षਾਤਮਕ ਹੋ ਕੇ।

ਲੈਗੇਸੀ ਕੋਡ ਰੀਫੈਕਟਰਨਗ ਸੌਫਟਵੇਅਰ ਇੰਜੀਨੀਅਰਿੰਗ ਵਿੱਚ ਸਭ ਤੋਂ ਉੱਚ-ਖਤਰੇ, ਉੱਚ-ਇਨਾਮ ਵਾਲੀਆਂ ਗਤੀਵਿਧੀਆਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ। ਮੇਰਾ ਤਰੀਕਾ ਸੁਰੱਖਿਆ ਨੂੰ ਤੇਜ਼ੀ ਤੋਂ ਵੱਧ ਪ੍ਰਾਥਮਿਕਤਾ ਦਿੰਦਾ ਹੈ। ਸਥਿਤੀ: ਮੈਂ ਇੱਕ ਟੀਮ ਵਿੱਚ ਸ਼ਾਮਿਲ ਹੋਇਆ/ਈ ਜੋ 7 ਸਾਲ ਪੁਰਾਣੇ ਮੋਨੋਲਿਥ ਨੂੰ ਮੈਂਟੇਨ ਕਰ ਰਹੀ ਸੀ ਜਿਸਦੀ ਕੋਈ ਟੈਸਟ ਕੋਵਰੇਜ ਨਹੀਂ ਸੀ, ਮੌਡੀਊਲਾਂ ਵਿੱਚ ਵੱਡੀ ਕਪਲਿੰਗ ਸੀ, ਅਤੇ ਕੋਈ ਡੌਕਯੂਮੈਂਟੇਸ਼ਨ ਨਹੀਂ ਸੀ। ਹਰ ਬਦਲਾਅ ਕਿਸੇ ਨਾ ਕਿਸੇ ਅਣਉਮੀਦ ਤੱਥ ਨੂੰ ਤੋੜਦਾ ਸੀ। ਮੇਰਾ ਅਪ੍ਰੋਚ: - ਪਹਿਲਾਂ ਕੈਰੈਕਟਰਾਈਜੇਸ਼ਨ ਟੈਸਟ — ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ, ਮੈਂ ਟੈਸਟ ਲਿਖੇ ਜੋ ਮੌਜੂਦਾ (ਕਈ ਵਾਰੀ ਗਲਤ) ਵਿਵਹਾਰ ਨੂੰ ਕੈਪਚਰ ਕਰਨ। ਇਸ ਨਾਲ ਸੁਰੱਖਿਆ ਨੈਟ ਬਣਿਆ। - Strangler Fig ਪੈਟਰਨ — "ਬਿਗ ਬੈਂਗ" ਰੀਰਾਈਟ ਦੇ ਬਦਲੇ, ਮੈਂ ਇੱਕ-ਇੱਕ ਮੌਡੀਊਲ ਨੂੰ ਬਦਲਿਆ ਜਦੋਂ ਕਿ ਸਿਸਟਮ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਚੱਲ ਰਿਹਾ ਸੀ - Architecture Decision Records (ADRs) — ਮੈਂ ਹਰ ਵੱਡੇ ਫੈਸਲੇ ਨੂੰ rationale ਸਮੇਤ ਡੌਕਯੂਮੈਂਟ ਕੀਤਾ ਤਾਂ ਜੋ ਟੀਮ ਨੂੰ ਇਹ ਪਤਾ ਰਹੇ ਕਿ ਬਦਲਾਵਾਂ ਦੇ ਪਿੱਛੇ "ਕਿਉਂ" ਹੈ - ਫੀਚਰ ਫਲੈਗਸ — ਨਵੀਆਂ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਫਲੈਗ ਦੇ ਪਿੱਛੇ ਚਲਦੀਆਂ ਸਨ, ਜਿਸ ਨਾਲ ਕੋਈ ਵੀ ਸਮੱਸਿਆ ਆਓ ਤਾਂ ਤੁਰੰਤ ਰੋਲਬੈਕ ਸੰਭਵ ਸੀ ਨਤੀਜਾ: ਛੇ ਮਹੀਨੇ ਵਿੱਚ, ਅਸੀਂ 0% ਤੋਂ 75% ਟੈਸਟ ਕੋਵਰੇਜ ਤੱਕ ਪਹੁੰਚ ਕੀਤੀ, ਔਸਤ ਡਿਪਲੋਇ ਸਮਾਂ 45 ਮਿੰਟ ਤੋਂ 8 ਮਿੰਟ ਤੱਕ ਘਟਾਇਆ, ਅਤੇ ਦੁਹਰਾਉਂਦੀਆਂ ਪ੍ਰੋਡਕਸ਼ਨ ਬਗ ਦੀਆਂ ਦੋ ਸ਼੍ਰੇਣੀਆਂ ਖ਼ਤਮ ਕੀਤੀਆਂ। ਪੂਰੇ ਰੀਫੈਕਟਰ ਦੌਰਾਨ ਕੋਈ ਅਣਯੋਜਿਤ ਡਾਉਨਟਾਈਮ ਨਹੀਂ ਸੀ। ਮੁੱਖ ਸਬਕ: ਰੀਫੈਕਟਰਨਗ ਨੂੰ ਇੱਕ ਇਕ-ਵਾਰੀ ਪ੍ਰੋਜੈਕਟ ਨਾ ਸਮਝੋ, ਬਲਕਿ ਇੱਕ ਚਲਦੀ ਰਹਿਣ ਵਾਲੀ ਅਭਿਆਸ ਵਜੋਂ ਲਵੋ। ਅਸੀਂ ਹਰ ਸਪ੍ਰਿੰਟ ਦੇ 20% ਤੱਕ ਟੈਕਨੀਕਲ ਕਰਜੇ ਦੀ ਘਟਾਈ ਲਈ ਅਲੋਕੇਟ ਕੀਤਾ, ਜਿਸ ਨਾਲ ਕੋਡਬੇਸ ਹਰ ਚੱਕਰ ਵਿੱਚ ਕਦਮ-ਬ-ਕਦਮ ਸਿਹਤਮੰਦ ਬਣਦਾ ਗਿਆ।

ਅਪ-ਟੂ-ਡੇਟ ਰਹਿਣਾ ਇੱਕ ਕਰੀਅਰ ਅਨੁਸ਼ਾਸਨ ਹੈ — ਪਰ "ਸ਼ਾਈਨੀ ਓਬਜੈਕਟ ਸਿੰਡ੍ਰੋਮ" ਤੋਂ ਬਚਣਾ ਵੀ ਇੱਕ ਅਨੁਸ਼ਾਸਨ ਹੈ। ਮੇਰਾ ਅਪ੍ਰੋਚ ਸਿੱਖਣ ਅਤੇ ਆਲੋਚਨਾਤਮਕ ਮੁੱਲਾਂਕਣ ਵਿਚ ਸਤੁਲਨ ਰੱਖਦਾ ਹੈ। ਮੇਰੇ ਨਿਯਮਤ ਸਰੋਤ: - ਇੰਜੀਨੀਅਰਿੰਗ ਬਲਾਗ: Spotify Engineering, Netflix Tech Blog, GitHub Engineering — ਇਹ ਸਕੇਲ 'ਤੇ ਅਸਲੀ ਦੁਨੀਆ ਦੇ ਫੈਸਲੇ ਕਵਰ ਕਰਦੇ ਹਨ - ਪੋਡਕਾਸਟਸ: Software Engineering Daily, Changelog, ਅਤੇ The Stack Overflow Podcast — ਕਮੇਟਸ ਦੌਰਾਨ ਸੁਣਦਾ/ਦੀ ਹਾਂ - ਉਹ RFC ਅਤੇ ਪ੍ਰੋਪੋਜ਼ਲ ਜਿਨ੍ਹਾਂ ਦੀਆਂ ਚਰਚਾਵਾਂ ਮੈਂ ਪ੍ਰੋਫੈਸ਼ਨਲ ਤੌਰ 'ਤੇ ਵਰਤਣ ਵਾਲੀਆਂ ਭਾਸ਼ਾਵਾਂ ਅਤੇ ਫਰੇਮਵਰਕਾਂ ਲਈ ਦੇਖਦਾ/ਦੀ ਹਾਂ - ਮੇਰੇ ਕੋਰ ਸਟੈਕ ਲਈ GitHub trending ਰੈਪੋਜ਼ ਅਤੇ ਰਿਲੀਜ਼ ਨੋਟਸ (ਹਫਤਾਵਾਰ) ਨਵੀਂ ਤਕਨਾਲੋਜੀ ਨੂੰ ਮੈਂ ਕਿਵੇਂ ਅੰਕਲਣ ਕਰਦਾ/ਦੀ ਹਾਂ: - ਕੰਮ 'ਤੇ ਪ੍ਰਸਤਾਵ ਪੇਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉਸ ਨਾਲ ਇੱਕ ਛੋਟਾ ਸਾਈਡ ਪ੍ਰੋਜੈਕਟ ਬਣਾਉਂਦਾ/ਦੀ ਹਾਂ — ਅਸਲੀ ਵਰਤੋਂ ਬਲੌਗ ਪੋਸਟਾਂ ਵਿੱਚ ਨਹੀਂ ਦਿਖਣ ਵਾਲੀਆਂ ਸੀਮਾਵਾਂ ਦਾ ਪਤਾ ਦਿੰਦੀ ਹੈ - ਕਮਿ ਯੂਨੀਟੀ ਹੈਲਥ ਚੈੱਕ ਕਰਦਾ/ਦੀ ਹਾਂ: GitHub ਤੇ ਐਕਟੀਵਿਟੀ, Stack Overflow ਉੱਤਰੇ, ਕਾਰਪੋਰੇਟ ਬੈਕਰਜ਼, ਅਤੇ ਬ੍ਰੇਕਿੰਗ ਚੇਂਜ ਫ੍ਰਿਕਵੈਂਸੀ - ਪੁੱਛਦਾ/ਦੀ ਹਾਂ: ਕੀ ਇਹ ਉਸ ਸਮੱਸਿਆ ਨੂੰ ਸੌਲਵ ਕਰਦਾ ਹੈ ਜੋ ਸਾਡੇ ਕੋਲ ਅਸਲ ਵਿੱਚ ਹੈ, ਜਾਂ ਸਿਰਫ਼ ਇੱਕ ਦਿਲਚਸਪ ਸਮੱਸਿਆ ਜਿਸਦਾ ਸਿਰਫ਼ ਸੁਣਨ ਵਧੀਆ ਲੱਗਦਾ ਹੈ? ਉਦਾਹਰਣ: ਜਦੋਂ edge computing ਟ੍ਰੈਂਡ ਬਣਿਆ, ਮੈਂ ਇੱਕ ਹਫ਼ਤੇ ਦੇ ਐਂਡ-ਟੀਮ ਦੇ ਅੰਤ 'ਤੇ Cloudflare Workers ਨਾਲ ਇੱਕ ਛੋਟਾ ਡੈਮੋ ਬਣਾਇਆ ਹਾ ਤਾਂ ਜੋ ਕੰਪਨੀ ਵਿੱਚ ਇਸ ਦੀ ਸਿਫਾਰਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਹਥੋਂ-ਹਥੋਂ ਸਮੱਸਿਆਵਾਂ ਦੀ ਪਛਾਣ ਹੋ ਜਾਵੇ। ਹਥ-ਅਨ-ਟਾਈਮ ਨੇ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਸੀਮਤਾ ਖੋਲੀ — ਸਾਡੇ ਅੰਦਰੂਨੀ ਓਥ ਸਰਵਿਸ ਤੱਕ ਪਹੁੰਚ ਨਹੀਂ — ਜੋ ਕਿ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਜਾ ਕੇ ਹੀ ਹਫਤਿਆਂ ਲੱਗਦੀ ਪਤੀ ਹੁੰਦੀ। ਮੈਂ ਕਾਲੀਨਤੌਰ "ਟੈਕ ਰਾਡਾਰ" ਸੈਸ਼ਨ ਤੀਹਰ-ਤੌਰ 'ਤੇ ਟੀਮ ਨਾਲ ਚਲਾਉਂਦਾ/ਦੀ ਹਾਂ ਤਾਂ ਜੋ ਤਕਨਾਲੋਜੀਆਂ ਨੂੰ ਕੈਟੇਗਰਾਈਜ਼ ਕੀਤਾ ਜਾ ਸਕੇ: adopt, trial, assess, ਜਾਂ hold।

ਦੋਹਾਂ REST ਅਤੇ GraphQL ਇੱਕੋ ਮੂਲ ਸਮੱਸਿਆ ਹੱਲ ਕਰਦੇ ਹਨ — HTTP ਦੇ ਜ਼ਰੀਏ ਡੇਟਾ ਐਕਸਪੋਜ਼ ਕਰਨਾ — ਪਰ ਉਹ ਬਹੁਤ ਵੱਖ-ਵੱਖ ਟਰੇਡ-ਆਫ਼ ਕਰਦੇ ਹਨ। REST (Representational State Transfer): - ਰਿਸੋਰਸ-ਆਧਾਰਿਤ ਐਂਡਪੌਇੰਟ: GET /users/42, POST /orders - ਰਿਸਪਾਂਸ ਸਰਵਰ-ਪਾਰਿਭਾਸ਼ਿਤ ਹੁੰਦੇ ਹਨ — ਕਲਾਇੰਟ ਨੂੰ ਉਹੀ ਮਿਲਦਾ ਜੋ ਸਰਵਰ ਫੈਸਲਾ ਕਰਦਾ ਹੈ - ਸ਼ਾਨਦਾਰ HTTP caching ਸਹਿਯੋਗ (ETags, Cache-Control headers ਆਸਾਨੀ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ) - ਸਮਝਣ, ਡੌਕਯੂਮੈਂਟ (OpenAPI/Swagger), ਅਤੇ ਟੈਸਟ ਕਰਨ ਲਈ ਸਧਾਰਨ - ਓਵਰ-ਫੈਚਿੰਗ (ਬਹੁਤ ਡੇਟਾ) ਜਾਂ ਅੰਡਰ-ਫੈਚਿੰਗ (ਕਈ ਰਿਕਵੇਸਟਾਂ ਦੀ ਲੋੜ) ਦਾ ਸਮੱਸਿਆ ਹੋ ਸਕਦਾ ਹੈ GraphQL: - ਸਿੰਗਲ ਐਂਡਪੌਇੰਟ; ਕਲਾਇੰਟ ਖੁਦ ਦੱਸਦਾ ਹੈ ਕਿ ਉਹ ਕਿਹੜੇ ਫੀਲਡ ਚਾਹੁੰਦਾ/ਦੀ ਹੈ - ਇੱਕ ਹੀ ਬੇਨਤੀ ਵਿੱਚ ਓਵਰ-ਫੈਚਿੰਗ ਅਤੇ ਅੰਡਰ-ਫੈਚਿੰਗ ਦੋਹਾਂ ਨੂੰ ਦੂਰ ਕਰਦਾ ਹੈ - ਮਜ਼ਬੂਤ ਟਾਈਪਡ ਸਕੀਮਾ ਜੋ ਜੀਵਤ ਡੌਕਯੂਮੈਂਟੇਸ਼ਨ ਵਾਂਗ ਕੰਮ ਕਰਦਾ ਹੈ - HTTP caching ਔਖਾ ਹੈ; ਕੁਏਰੀ-ਲੇਵਲ caching ਜਾਂ persisted queries ਲੋੜੀਂਦੇ ਹਨ - ਉੱਚ ਸ਼ੁਰੂਆਤੀ ਸੈਟਅਪ ਖਰਚ; N+1 ਕਵੇਰੀ ਸਮੱਸਿਆਵਾਂ ਲਈ DataLoader ਪੈਟਰਨ ਵਰਤਨਾ ਪੈਂਦਾ ਹੈ ਕਦੋਂ ਮੈਂ ਹਰ ਇੱਕ ਚੁਣਦਾ/ਦੀ ਹਾਂ: - REST: ਸਧਾਰਣ CRUD, ਪਬਲਿਕ APIs, ਮਾਈਕ੍ਰੋਸਰਵਿਸਜ਼ ਨਾਲ ਜਦੋਂ ਕੰਟਰੈਕਟ ਵੱਧ ਪਰਿਭਾਸ਼ਿਤ ਹੋਣ, ਜਦੋਂ caching ਨੁੰਨਤਾ ਮਖ਼ਤਅਲ ਹੈ - GraphQL: ਮੋਬਾਈਲ ਕਲਾਇੰਟ ਜਿਹੜੇ payload ਘੱਟ ਰੱਖਣੇ ਚਾਹੁੰਦੇ ਹਨ, ਡੈਸ਼ਬੋਰਡ ਜਿੱਥੇ ਵੱਖ-ਵੱਖ ਤਰ੍ਹਾਂ ਦਾ ਡੇਟਾ ਲੋੜੀਂਦਾ ਹੈ, BFF (Backend for Frontend) ਪੈਟਰਨ, ਤੇਜ਼ ਪ੍ਰੋਡਕਟ ਇਟਰੇਸ਼ਨ ਜਿੱਥੇ frontend ਡੇਟਾ ਜ਼ਰੂਰਤ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਦੀ ਹੈ ਅਸਲ ਫੈਸਲਾ: ਸਾਡੇ ਮੋਬਾਈਲ ਐਪ ਲਈ ਅਸੀਂ REST ਤੋਂ GraphQL 'ਤੇ ਬਦਲੇ ਅਤੇ ਔਸਤ payload ਸਾਈਜ਼ 62% ਘੱਟ ਕਰ ਦਿੱਤੀ, ਜਿਸ ਨਾਲ 3G ਨੈੱਟਵਰਕ 'ਤੇ ਪੇਜ ਲੋਡ ਸਮਾਂ 1.1 ਸੈਕਿੰਡ ਘਟਿਆ — ਸਾਡੇ ਟਾਰਗਿਟ ਮਾਰਕੀਟ (emerging markets) ਲਈ ਇਹ ਵੱਡਾ UX ਸੁਧਾਰ ਸੀ।

ਪ੍ਰੋਡਕਸ਼ਨ ਪਰਫਾਰਮੈਂਸ ਮੁੱਦਿਆਂ ਨਾਲ ਚੰਗੀ ਤਰ੍ਹਾਂ ਨਿਪਟਣਾ ਮੂਲ ਰੂਪ ਵਿੱਚ ਹੈਬਲਟੀ (observability) ਇੰਫਰਾਸਟ੍ਰੱਕਚਰ ਹੋਣ ਅਤੇ ਸਮੱਸਿਆ ਆਉਣ 'ਤੇ ਸਾਫ-ਸਪਸ਼ਟ ਡਾਇਗਨੋਸਟਿਕ ਪ੍ਰਕਿਰਿਆ ਹੋਣ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਸਮੱਸਿਆ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ — ਇੰਸਟ੍ਰੂਮੈਂਟੇਸ਼ਨ: - ਡਿਸਟ੍ਰਿਬਿਊਟਿਡ ਟਰੇਸਿੰਗ (Jaeger ਜਾਂ AWS X-Ray) ਤਾਂ ਜੋ ਸੇਵਾ-ਸੀਮਾਵਾਂ ਵਿੱਚ ਲੇਟੈਂਸੀ ਟਰੈਕ ਕੀਤੀ ਜਾ ਸਕੇ - APM ਟੂਲਿੰਗ (Datadog ਜਾਂ New Relic) ਐਪਲੀਕੇਸ਼ਨ-ਸਤਹ ਮੈਟ੍ਰਿਕਸ ਅਤੇ ਏਰਰ ਰੇਟਸ ਲਈ - ਸਟਰੱਕਚਰਡ ਲੌਗਿੰਗ ਵਿਥ ਰਿਕਵੇਸਟ IDs ਤਾਂ ਜੋ ਮੈਂ ਇਕ ਯੂਜ਼ਰ ਦੀ ਯਾਤਰਾ ਸਿਸਟਮ ਵਿੱਚ ਟਰੇਸ ਕਰ ਸਕਾਂ - SLOs (Service Level Objectives) ਨਾਲ ਅਲਰਟਿੰਗ — ਤਾਂ ਜੋ ਮੈਂ ਡਿਗ੍ਰੇਡੇਸ਼ਨ ਬਾਰੇ ਉਪਭੋਗੀਆਂ ਦੀ ਸ਼ਿਕਾਇਤ ਤੋਂ ਪਹਿਲਾਂ ਪਤਾ ਲੱਗੇ ਜਦੋਂ ਪਰਫਾਰਮੈਂਸ ਮੁੱਦਾ ਸਾਹਮਣੇ ਆਉਂਦਾ ਹੈ: - ਪਹਿਲਾਂ ਦੁਹਰਾਉ — ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਬਿਨਾਂ ਦੁਹਰਾਏ ਑ਪਟੀਮਾਈਜ਼ ਨਾ ਕਰੋ - ਪ੍ਰੋਫ਼ਾਈਲ ਕਰੋ, ਅੰਦਰਗੱਲ ਨਾ ਕਰੋ — ਅਸਲ ਬੋਟਲਨੇਕ ਆਮ ਤੌਰ 'ਤੇ ਉੱਥੇ ਨਹੀਂ ਹੁੰਦਾ ਜਿੱਥੇ ਮੈਂ ਉਮੀਦ ਕਰਦਾ/ਦੀ ਹਾਂ। ਆਮ ਕਾਰਣ: N+1 ਕਵੇਰੀਜ਼, ਗਾਇਮ ਹੋਏ ਡੇਟਾਬੇਸ ਇੰਡੈਕਸ, ਸਿੰਕਰੋਨਸ I/O ਜੋ async ਕੋਡ ਨੂੰ ਰੋਕ ਰਿਹਾ ਹੋਵੇ, ਮੈਮੋਰੀ ਲੀਕ ਤੋਂ GC ਦਬਾਅ - ਰੂਟ ਕਾਰਨ ਸੰਧਾਨ ਕਰੋ — ਲਕੜੀ ਦੀ ਕਟਾਈ ਜਿਹੇ ਲੱਛਣ ਨੂੰ ਠੀਕ ਕਰਨ ਦੀ ਬਜਾਏ; 5× ਤੇਜ਼ ਕਵੇਰੀ ਕੈਸ਼ ਹਿਡਿੰਗ ਤੋਂ ਬਿਹਤਰ ਹੈ - ਮੈਟ੍ਰਿਕਸ ਨਾਲ ਵੈਲੀਡੇਟ ਕਰੋ — ਡਿਪਲੋਇ ਕਰੋ ਅਤੇ ਉਸੇ ਡੈਸ਼ਬੋਰਡਾਂ ਨਾਲ ਫਿਕਸ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ ਜੋ ਸਮੱਸਿਆ ਦਿਖਾਈ ਸੀ ਉਦਾਹਰਣ: ਇੱਕ ਚੈਕਆਉਟ API ਸੇਲ इਵੈਂਟ ਦੌਰਾਨ P99 ਲੈਟੈਂਸੀ 4 ਸਕਿੰਡ ਤੱਕ ਚੱਲ ਗਿਆ। ਟਰੇਸਿੰਗ ਨੇ ਦਿਖਾਇਆ ਕਿ ਇੱਕ ਸਿੰਗਲ ORM ਮੈਥਡ ਪ੍ਰਤੀ ਰਿਕਵੇਸਟ 147 SQL ਕਵੇਰੀਜ ਜਨਰੇਟ ਕਰ ਰਿਹਾ ਸੀ (product variants 'ਤੇ N+1)। eager loading ਜੋੜਨ ਨਾਲ P99 180ms ਤੱਕ ਆ ਗਿਆ। ਫਿਕਸ 3 ਲਾਈਨਾਂ ਕੋਡ ਦੀ ਸੀ — ਪਰ ਕੇਵਲ ਪ੍ਰੋਫ਼ਾਈਲਿੰਗ ਨੇ ਇਹ ਖੋਲ੍ਹਿਆ। ਪੋਸਟ-ਇਨਸਿਡੈਂਟ, ਮੈਂ ਇੱਕ blame-less ਪੋਸਟ-ਮੋਰਟਮ ਲਿਖਦਾ/ਦੀ ਹਾਂ ਜਿਸ ਵਿੱਚ ਟਾਈਮਲਾਈਨ, ਰੂਟ ਕਾਰਨ, ਅਤੇ ਮੁੜ ਹੋਣ ਤੋਂ ਰੋਕਣ ਲਈ ਐਕਸ਼ਨ ਆਈਟਮ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ।

ਮੇਰਾ ਕਲਾਉਡ ਤਜ਼ਰਬਾ ਮੁੱਖ ਤੌਰ 'ਤੇ AWS ਉੱਤੇ ਹੈ, ਕੁਝ ਖਾਸ ਵਰਕਲੋਡ ਲਈ GCP ਅਤੇ Azure ਦਾ ਐਕਸਪੋਜ਼ਰ ਵੀ ਹੈ। ਮੈਂ Infrastructure-as-code-ਫਰਸਟ ਮਨੋਭਾਉ ਨਾਲ ਕੰਮ ਕਰਦਾ/ਦੀ ਹਾਂ — ਜੇ ਇਹ ਵਰਜ਼ਨ ਕੰਟਰੋਲ ਵਿੱਚ ਨਹੀਂ ਹੈ ਤਾਂ ਇਹ ਮੌਜੂਦ ਨਹੀਂ ਮੰਨਦਾ। AWS ਸਰਵਿਸਾਂ ਜਿਨ੍ਹਾਂ ਨੂੰ ਮੈਂ ਨਿਯਮਤ ਤੌਰ 'ਤੇ ਵਰਤਦਾ/ਦੀ ਹਾਂ: - Compute: EC2 (cost optimisation ਲਈ Spot ਸਮੇਤ), ECS/EKS ਕਨ­teਨਰ orchestration ਲਈ, Lambda ਇਵੈਂਟ-ਡ੍ਰਿਵਨ ਵਰਕਲੋਡ ਲਈ - Storage & databases: RDS (PostgreSQL, Aurora), DynamoDB low-latency key-value ਐਕਸੈੱਸ ਲਈ, S3 ਨਾਲ lifecycle polisiਜ਼, ElastiCache (Redis) - Networking & delivery: ALB, CloudFront CDN, Route 53, VPC ਡਿਜ਼ਾਈਨ ਪ੍ਰਾਈਵੇਟ ਸਬਨੇਟਸ ਅਤੇ NAT ਗੇਟਵੇਜ਼ ਨਾਲ - Observability: CloudWatch ਮੈਟ੍ਰਿਕਸ, ਅਲਾਰਮਾਂ, ਅਤੇ ਲੌਗ ਇਨਸਾਇਟਸ; X-Ray ਡਿਸਟ੍ਰਿਬਿਊਟਿਡ ਟਰੇਸਿੰਗ ਲਈ ਮੈਂ ਇੰਫਰਾਸਟ੍ਰੱਕਚਰ ਨੂੰ ਕਿਸ ਤਰ੍ਹਾਂ ਹੈਂਡਲ ਕਰਦਾ/ਦੀ ਹਾਂ: - Terraform ਸਾਰੇ ਇੰਫ੍ਰਾਸਟ੍ਰੱਕਚਰ ਲਈ — ਰਿਯੂਜ਼ਬਲ ਕੰਪੋਨੈਂਟ ਲਈ ਮੋਡੀਊਲ, S3 ਵਿੱਚ ਰਿਮੋਟ ਸਟੇਟ ਅਤੇ DynamoDB ਲਾਕਿੰਗ - CI/CD GitHub Actions ਜਾਂ Jenkins ਨਾਲ — ਆਟੋਮੇਟਿਡ ਟੈਸਟਿੰਗ, ਸਟੇਜਿੰਗ ਡਿਪਲੋਇਜ਼, ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਪ੍ਰੋਮੋশন ਗੇਟਸ - Docker ਸਥਿਰ ਵਾਤਾਵਰਣਾਂ ਲਈ; EKS ਜਾਂ ECS orchestration ਟੀਮ ਦੀ ਪਛਾਣ ਉਤੇ ਨਿਰਭਰ - IAM ਲਈ principle of least privilege — roles, not users; ਕਿਤੇ ਵੀ ਹਾਰਡਕੋਡ ਕੀਤੇ ਗਏ ਕ੍ਰੈਡੈਂਸ਼ਿਅਲ ਨਹੀਂ ਉਦਾਹਰਣ: ਮੈਂ ਇੱਕ ਫਿਨਟੈਕ ਕਲਾਇੰਟ ਲਈ AWS ਉੱਤੇ multi-region active-passive ਆਰਕੀਟੈਕਚਰ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਜਿਸਦਾ RPO 15 minutes ਅਤੇ RTO 30 minutes ਸੀ। Aurora Global Database, cross-region S3 replication, ਅਤੇ Route 53 health-check-based failover ਵਰਤੇ ਗਏ। ਕੁੱਲ ਵਾਧੂ ਮਹੀਨਾਵਾਰ ਲਾਗਤ: £280, ਇਕ ਐਸਾ ਸਿਸਟਮ ਜੋ £2M/day ਦੇ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਪ੍ਰੋਸੈਸ ਕਰ ਰਿਹਾ ਸੀ।

High-traffic ਲਈ ਸਿਸਟਮ ਡਿਜ਼ਾਈਨ ਮੂਲ ਰੂਪ ਵਿੱਚ ਉਹਨਾਂ ਬੋਟਲਨੇਕਸ ਨੂੰ ਸਮਝਣ ਅਤੇ consistency, availability, ਅਤੇ cost ਦੇ ਵਿਚਕਾਰ ਸੋਚ-ਸਮਝ ਕੇ ਟਰੇਡ-ਆਫ਼ ਕਰਨ ਬਾਰੇ ਹੈ। ਮੇਰੀ ਪ੍ਰਕਿਰਿਆ: - ਲੋੜਾਂ ਇਕੱਠਾ ਕਰੋ: ਅੰਦਾਜ਼ਿਤ concurrent users, peak QPS, read/write ਅਨੁਪਾਤ, latency SLOs (P50/P99), consistency ਲੋੜਾਂ, ਭੂਗੋਲਿਕ ਵਿਕਰਤੀ - ਕੇਪੇਸਿਟੀ ਦਾ ਅਨੁਮਾਨ ਲਗਾਓ: ਬਾਕ-ਆਫ-ਐਨਵੈਲਪ ਗਣਨਾਵਾਂ ਪਹਿਲਾਂ — ਚਾਰਟ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਪੀਕ 'ਤੇ ਸਾਨੂੰ ਕਿੰਨੇ ਸਰਵਰਾਂ ਦੀ ਲੋੜ ਹੋਏਗੀ? ਡੇਟਾਬੇਸ ਲਿਖਾਈ throughput ਕੀ ਹੋਵੇਗਾ? - horizontal scale ਲਈ ਡਿਜ਼ਾਈਨ: stateless application servers ਨਾਲ ਇੱਕ load balancer ਪਿੱਛੇ, ਤਾਂ ਕਿ ਕੋਈ ਵੀ ਸਰਵਰ ਕਿਸੇ ਵੀ ਰਿਕਵੇਸਟ ਨੂੰ ਹੈਂਡਲ ਕਰ ਸਕੇ ਆਮ ਪੈਟਰਨ ਜੋ ਮੈਂ ਲਗਾਉਂਦਾ/ਦੀ ਹਾਂ: - caching: Redis hot ਡੇਟਾ ਲਈ (session state, ਅਕਸਰ ਪੜ੍ਹੀਆਂ ਰਿਕਾਰਡ), CDN (CloudFront) static assets ਲਈ — origin ਸਰਵਰਾਂ ਨੂੰ dynamic ਰਿਕਵੇਸਟਾਂ ਲਈ ਖਾਲੀ ਰੱਖਦਾ ਹੈ - database scaling: read replicas read-heavy ਵਰਕਲੋਡ ਲਈ, connection pooling (PgBouncer), ਅਤੇ extreme scale ਲਈ sharding - async processing: message queues (SQS, Kafka) ਭਾਰੇ ਟਾਸਕਾਂ ਨੂੰ request cycle ਤੋਂ ਅਲੱਗ ਕਰਦੇ ਹਨ — image processing, emails, notifications - circuit breakers ਅਤੇ bulkheads: ਜਦੋਂ ਕੋਈ ਡਿਪੈਂਡੇੰਸੀ degrade ਹੋਵੇ ਤਾਂ cascade failures ਨੂੰ ਰੋਕਦੇ ਹਨ - graceful degradation: ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਕਿ ਜਦੋਂ downstream ਸਰਵਿਸ ਅਨਉਪਲਬਧ ਹੋਵੇ ਤਾਂ ਸਿਸਟਮ ਕੀ ਕਰੇ — stale data ਸਰਵ ਕਰੇ? ਫੀਚਰ ਅਪਰੇਟਿਵੇ ਨਾ ਕਰੋ? ਕਦੇ ਵੀ ਚੁਪਕੇ ਨਾਲ fail ਨਾ ਹੋਵੇ। ਉਦਾਹਰਣ: ਇੱਕ flash-sale ਸਿਸਟਮ ਲਈ ਜੋ 50,000 concurrent users ਨੂੰ 2-ਘੰਟੇ ਦੀ ਖਿੜਕੀ ਦੌਰਾਨ ਸੰਭਾਲਦਾ ਹੈ, ਮੈਂ ਇੱਕ pre-warmed Redis inventory ਲੇਅਰ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਜਿਸਨੇ ਸਾਰੀ ਰੀਡ ਟ੍ਰੈਫਿਕ ਨੂੰ ਅਪਸੋਰਬ ਕੀਤਾ, purchase requests ਲਈ write-ahead queue ਰੱਖੀ ਤਾਂ ਕਿ overselling ਨਾ ਹੋਵੇ, ਅਤੇ SQS queue depth ਨਾਲ ਟ੍ਰਿਗਰ ਹੋਣ ਵਾਲੇ auto-scaling ECS tasks। ਸਿਸਟਮ ਨੇ ਪ੍ਰੋਜੈਕਟ ਕੀਤੇ ਪੀਕ ਦਾ 3× ਹੰਡੀ ਕਰ ਲਿਆ ਬਿਨਾਂ ਕਿਸੇ dropped request ਦੇ।