Tech lead کے طور پر پہلے “دس گنا صارفین” کو متوقع استعمال، service targets اور ٹیم کی قابلِ عمل منصوبہ بندی میں بدلوں گا۔ Registered accounts اکیلے مصروف ترین وقت کی request تعداد نہیں بتاتے۔
فرض کریں کاروبار order platform کی مہم چلا رہا ہے۔ سوال یہ ہے کہ دستیاب وقت اور بجٹ میں گاہک مہم کے دوران browse، خرید اور confirmation حاصل کر سکیں گے یا نہیں۔
Product سے پوچھیں صارف کب آئیں گے اور کیا کریں گے۔ سال بھر کی تدریجی ترقی، سب کو ایک ساتھ لانے والی مہم سے مختلف ہے۔
مثال کے طور پر 100,000 accounts میں 1% بیک وقت active ہوں تو 1,000 concurrent صارف ہیں۔ 5% ہوں تو 5,000 ہیں۔ یہ مثالی مفروضے ہیں، default تناسب نہیں۔ Request frequency اور ہر request کا کام پھر بھی اندازہ کرنا ہے۔
مہم کا load لکھیں:
یوں servers دس گنا کرنے کی مبہم ہدایت کے بجائے قابلِ آزمائش workload ملتا ہے۔
اہم journeys کے لیے قابلِ قبول response time، error rate اور completion طے کریں۔ جہاں اہم ہو data freshness اور recovery توقع بھی لکھیں۔ Report دیر سے آ سکتی ہے مگر checkout failure قابلِ قبول نہ ہو۔
[Campaign assumptions] -> [Expected workload] -> [Service targets]
|
[Acceptance tests]
Targets تکنیکی کام کو گاہک کے نتیجے سے جوڑتے ہیں۔ ان سے معلوم ہوتا ہے کہ بہتری کافی ہے یا نہیں اور دباؤ میں کون سی کمی برداشت ہو سکتی ہے۔
Production مشاہدات اور نمائندہ load tests استعمال کریں۔ Slow queries، database connections، CPU، memory، queue age اور external quotas دیکھیں۔ صرف random requests نہیں، مقبول اشیا کی غیر مساوی traffic بھی شامل کریں۔
Database connections حد ہوں تو application nodes بڑھانا contention بڑھا سکتا ہے۔ Payment provider کا quota حد ہو تو تیز application اسے نہیں بڑھاتی۔
عام operation کے ساتھ cold cache اور instance loss بھی آزمائیں۔ مہم میں recovery capacity چاہیے، صرف مثالی test چلانے جتنی نہیں۔
| مشاہدہ | ممکنہ اقدام | ضروری ثبوت |
|---|---|---|
| بار بار مہنگی reads | Query بہتر یا مناسب نتائج cache | قابلِ قبول تازگی کے ساتھ کم database کام۔ |
| Background tasks خریداری سے مقابلہ کرتی ہیں | Capacity محدود یا الگ کریں | Background load میں checkout درست رہے۔ |
| Dependency quota ناکافی | اضافہ لیں یا admission قابو کریں | Confirmed quota اور حد پر tested رویہ۔ |
| چھوٹے fixes کے بعد capacity کم | Scaling یا بڑا design change دیکھیں | ناپا فائدہ، migration plan اور لاگت۔ |
ہر اقدام کو مالک، بجٹ، dependencies، آخری تاریخ اور acceptance test دیں۔ صرف implementation نہیں، deployment، عملی تربیت اور on-call تیاری شامل کریں۔
گاہک کے اثر اور delivery risk کے مطابق ترجیح دیں۔ بڑی rewrite یا sharding کو ثابت وجہ اور migration و verification کا کافی وقت چاہیے۔
تبدیلیاں قابلِ انتظام مراحل میں دیں اور journeys ساتھ آزمائیں۔ طے کریں کب traffic بڑھانا، اضافہ روکنا یا rollback کرنا ہے۔ Data format تبدیلی میں سادہ rollback کی جگہ آگے کی سمت recovery چاہیے ہو سکتی ہے۔
Controlled degradation تیار کریں: اختیاری export مؤخر، background کام محدود یا اہم عملیات بچاتے ہوئے اضافی requests رد کریں۔ جانچیں کہ controls واقعی load کم کرتے اور گاہک کو واضح نتیجہ دیتے ہیں۔
ہدف تاریخ یا بجٹ میں نہ آئے تو product کو ٹھوس انتخاب دیں: صارفین مرحلہ وار لائیں، مہنگا feature گھٹائیں یا ناپی رکاوٹ پر سرمایہ لگائیں۔ ہر انتخاب کا گاہک اثر اور غیر یقینی صورت سمجھائیں۔
یاد رکھیں: ترقی کے مفروضے → service targets → ناپی حدیں → مالکوں والا roadmap → rehearsed rollout۔ Tech lead لوگوں، پیسے اور recovery سمیت capacity plan دیتا ہے۔
تفصیلی جوابات کے ساتھ IT انٹرویو سوالات کی ایک لائبریری — جونیئر سے سینئر تک۔
عطیہ دیں