ریٹ کی حدود سے آگے: Codex اور Sora تک ایکسیس کو بڑھانا

گزشتہ سال کے دوران، Codex اور Sora دونوں کو تیزی سے اپنایا گیا ہے، اور ان کا استعمال ہماری ابتدائی توقعات سے کہیں زیادہ بڑھ گیا ہے۔ ہم نے ایک مستقل رجحان دیکھا ہے: صارفین بھرپور طریقے سے استعمال شروع کرتے ہیں، حقیقی فائدہ حاصل کرتے ہیں، اور پھر اچانک استعمال کی حدوں (rate limits) سے ٹکرا جاتے ہیں۔

درخواستوں کی حد (Rate limits) طلب کو متوازن رکھنے اور سب کے لیے منصفانہ رسائی یقینی بنانے میں مدد دیتی ہیں؛ تاہم جب صارفین کو واقعی فائدہ حاصل ہو رہا ہو تو اچانک سخت حد پر پہنچ جانا جھنجھلاہٹ کا باعث بن سکتا ہے۔ ہم چاہتے تھے کہ صارفین کے لیے آگے بڑھنے کا ایک طریقہ ہو، جبکہ سسٹم کی کارکردگی اور ہمارے طریقہ کار پر صارفین کا اعتماد بھی قائم رہے۔

اس مسئلے کو حل کرنے کے لیے، ہم نے ایک ریئل ٹائم ایکسیس انجن تیار کیا جو استعمال کو شمار کرتا ہے۔ اس انجن کی تہوں میں سے ایک تہہ کریڈٹس خریدنے کی صلاحیت ہے۔ جب صارفین اپنی ریٹ لمٹس سے تجاوز کر جاتے ہیں، تو کریڈٹس انہیں اپنے کریڈٹ بیلنس کو خرچ کر کے ہماری مصنوعات کا استعمال جاری رکھنے کی اجازت دیتے ہیں۔

اس کے پس منظر میں ایک پیچیدہ نظام کارفرما ہے جو ایک ہی ایکسیس ماڈل میں لمٹس ، ریئل ٹائم میں استعمال کی نگرانی، اور کریڈٹ بیلنس کو یکجا کرتا ہے۔ یہ تحریر وضاحت کرتی ہے کہ Codex اور Sora کو بڑے پیمانے پر پھیلانے کے لیے ایکسیس کنٹرول پر ازسرِنو غور کیوں ضروری تھا، ایک قابلِ تصدیق درست اور ریئل ٹائم سسٹم ہر درخواست پر شرحی حدود (rate limits) اور کریڈٹس کو کس طرح یکجا کرتا ہے، اور یہی بنیاد اب دونوں مصنوعات کے لیے مزید رسائی کے امکانات کیسے کھول رہی ہے۔

بڑے تناظر میں دیکھیں تو، روایتی رسائی کے ماڈل اکثر ایک انتخاب پر مجبور کرتے ہیں:

• ریٹ لمٹس شروع میں مددگار ثابت ہو سکتی ہیں، لیکن جب یہ ختم ہو جاتی ہیں تو صارفین کو بُرا تجربہ ہوتا ہے: “بعد میں واپس آئیں”
• استعمال پر مبنی بلنگ لچکدار ضرور ہے، مگر اس میں صارف کو پہلے ہی ٹوکن سے ادائیگی کرنی پڑتی ہے—جو ابتدائی تجربہ اور کھوج کے لیے موزوں نہیں

Codex اور Sora کے لیے، ان میں سے کوئی بھی اکیلا کافی نہیں تھا۔ اگر ہم محض استعمال کی حدیں (rate limits) بڑھا دیں تو طلب کو متوازن رکھنے اور منصفانہ رسائی کو یقینی بنانے والے اہم ضابطے ختم ہو جائیں گے، اور سب کو سروس فراہم کرنے کی گنجائش بھی جلد ختم ہو جائے گی۔ اور اگر ہم مکمل طور پر غیر ہم وقتی (asynchronous) استعمالی بلنگ پر انحصار کریں تو تاخیر، حد سے زیادہ استعمال (overages)، یا حساب کتاب میں عدم مطابقت جیسے مسائل پیدا ہو جائیں گے—بالکل وہی مسائل جو صارفین کو اُس وقت سب سے زیادہ محسوس ہوتے ہیں جب وہ بھرپور طور پر مصروف ہوتے ہیں۔

اس کے بجائے ہمیں ایک واحد ہائبرڈ نظام کی ضرورت تھی جو ریئل ٹائم لمٹس کو 'پے ایز یو گو' ایکسیس کے ساتھ یکجا کرے:

اس سسٹم کا کام تھا:

• ریٹ لیمٹس نافذ کریں جب تک وہ پوری نہ ہو جائیں
• بغیر کسی رکاوٹ کے کریڈٹس میں منتقل ہوں اسی درخواست کے اندر
• ریئل ٹائم میں فیصلہ کرنا
• کریڈٹ کے استعمال کو ٹریک کرتے وقت انتہائی درست اور قابلِ جانچ (auditable) بنے رہنا

ہم نے جو بنیادی تصوراتی تبدیلی کی، اس میں رسائی (access) کو ایک فیصلاتی واٹر فال کے طور پر ماڈل کرنا شامل تھا۔ “کیا اِس کی اجازت ہے؟” پوچھنے کے بجائے، ہم پوچھتے ہیں “کتنے کی اجازت ہے، اور کہاں سے؟” جب استعمال کو شمار کیا جاتا ہے، تو سسٹم درج ذیل ترتیب سے گزرتا ہے:

یہ ماڈل اس بات کی عکاسی کرتا ہے کہ صارفین واقعتاً پروڈکٹ کا تجربہ کیسے کرتے ہیں. ریٹ لمٹس، مفت درجے (free tiers)، کریڈٹس، پروموشنز، اور ادارہ جاتی مراعات (enterprise entitlements) دراصل ایک ہی فیصلہ جاتی نظام (decision stack) کی مختلف تہیں ہیں۔ صارف کے نقطۂ نظر سے، وہ “سسٹمز تبدیل” نہیں کرتے—وہ بس Codex اور Sora کا استعمال جاری رکھتے ہیں۔ اسی لیے کریڈٹس غیر مرئی محسوس ہوتے ہیں: وہ بس واٹر فال میں ایک اور عنصر ہیں.

ہم نے کریڈٹ کے استعمال کو سنبھالنے کے لیے تھرڈ پارٹی استعمالی بلنگ اور میٹرنگ پلیٹ فارمز کا جائزہ لیا۔ وہ انوائسنگ اور رپورٹنگ کے لیے تو موزوں تھے، لیکن دو اہم تقاضوں پر پورا نہیں اترتے تھے:

جب کسی صارف کی لمٹ ختم ہو جائے اور اس کے پاس کریڈٹس دستیاب ہوں، تو سسٹم کو فوراً معلوم ہونا چاہیے۔ بہترین کوشش یا تاخیر سے کی گئی گنتی غیر متوقع بلاکس، غیر مستقل بیلنس، اور غلط چارجز کی صورت میں ظاہر ہوتی ہے۔ Codex اور Sora جیسے انٹرایکٹو پروڈکٹس کے لیے، وہ ناکامیاں نمایاں اور مایوس کن نظر آتی ہیں۔

ہمیں ہر نتیجے میں شفافیت فراہم کرنے کی بھی ضرورت تھی:

• کیوں ایک درخواست کی اجازت دی گئی یا بلاک کی گئی
• کتنا استعمال ہوا
• کون سی پابندیاں یا توازنات لاگو کیے گئے

اس صلاحیت کو کسی الگ استعمالی بلنگ پلیٹ فارم میں تنہا طور پر حل کرنے کے بجائے ہمارے فیصلاتی واٹر فال (decision waterfall) میں گہرائی سے انٹیگریٹ ہونا ضروری تھا، تاکہ نظام صرف عمل کے ایک حصے کو دیکھنے تک محدود نہ رہے بلکہ پوری تصویر کو ساتھ لے کر چلے۔ صارفین کو اعتماد پر سمجھوتہ کیے بغیر ہماری مصنوعات تک رسائی دینے کے لیے ہمیں درستگی، بروقت عمل (timing)، اور مکمل نگرانی و شفافیت (observability) پر پورا اختیار درکار تھا۔ اسی ضرورت نے ہمیں اندرونِ خانہ (in-house) حل تیار کرنے کی طرف مائل کیا۔

اسے مزید فعال کرنے کے لیے، ہم نے ایک تقسیم شدہ (distributed) استعمال اور بیلنس کا نظام تیار کیا جو خاص طور پر ہم وقتی (synchronous) رسائی (ایکسیس) کے فیصلوں کے لیے ڈیزائن کیا گیا ہے۔

اعلی سطح پر، سسٹم:

• ہر صارف اور ہر فیچر کے استعمال کو ٹریک کرتا ہے
• ریٹ-لمٹ ونڈوز کو برقرار رکھتا ہے
• ریئل-ٹائم کریڈٹ بیلنس کو برقرار رکھتا ہے
• اسٹریمنگ غیر ہم وقتی (async) پروسیسر کے ذریعے بیلنس کو آئیڈیم پوٹنٹ انداز میں ڈیبٹ کرتا ہے

ہر درخواست ایک ایسے تشخیصی راستے (evaluation path) سے گزرتی ہے جو ریئل ٹائم میں یہ فیصلہ کرتا ہے کہ کتنا استعمال اجازت کے دائرے میں ہے—یعنی ہم-وقتی طور پر ریٹ لمٹس سے کھپت شمار کرتا ہے اور ضرورت پڑنے پر کریڈٹس کی دستیابی کی تصدیق کرتا ہے؛ پھر ایک حتمی نتیجہ کے ساتھ لوٹتا ہے، جبکہ کریڈٹ کی کٹوتیاں بعد میں غیر ہم-وقتی طور پر نمٹا دی جاتی ہیں۔ اس سے تمام مصنوعات میں رویّے کی یکسانیت برقرار رہتی ہے اور مختلف ٹیموں کے درمیان منطق (logic) کی غیر ضروری تکرار ختم ہو جاتی ہے۔

اس سسٹم کے اہم ڈیزائن اصولوں میں سے ایک یہ ہے کہ ہمیں یہ ثابت کرنے کے قابل ہونا چاہیے کہ ہماری بِلنگ درست ہے۔ یہ ہمارے کریڈٹ سپورٹ کی بنیادوں کی عکاسی کرتا ہے، جن کی ابتدا ادارہ جاتی (enterprise) صارفین سے ہوئی تھی۔ اوپر دکھائے گئے سسٹم ڈائیگرام میں ہمارے پاس تین الگ الگ ڈیٹا سیٹس ہیں جو آپس میں جڑے ہوئے ہیں:

• پروڈکٹ کے استعمال کے ایونٹس: صارف نے حقیقت میں کیا کیا
• مونیٹائزیشن ایونٹس: ہم صارفین سے ان کے استعمال کے بدلے کیا چارج کرتے ہیں
• بیلنس کی اپ ڈیٹس: ہم نے صارف کے کریڈٹ بیلنس میں کتنی تبدیلی کی اور اس کی وجہ کیا تھی

یہ ڈیٹاسیٹس کوئی اتفاقی ضمنی پیداوار نہیں ہیں؛ یہ حقیقت میں سسٹم کو چلاتے ہیں، اور ہر ڈیٹاسیٹ اگلے کو متحرک کرتا ہے۔ جو کچھ پیش آیا، اس سے جڑے ممکنہ چارجز، اور جو رقم ہم نے ڈیبٹ کی، ان تینوں کو الگ الگ رکھنے سے ہمیں ہر سطح پر آزادانہ طور پر آڈٹ کرنے، دوبارہ چلانے (replay)، اور حساب کی مکمل مطابقت قائم کرنے کی سہولت ملتی ہے۔ یہ ایک دانستہ سمجھوتہ (intentional trade-off) ہے جس میں ہم کریڈٹ بیلنس کی اپڈیٹس میں معمولی تاخیر کی قیمت پر قابلِ تصدیق درستگی کو ترجیح دے رہے ہیں۔ ہم نے یہ کیسے ممکن بنایا:

• تمام صارف سرگرمی کے لیے پروڈکٹ کے استعمال کے ایونٹس شائع کیے جاتے ہیں، چاہے اس سے کریڈٹ کے استعمال میں اضافہ ہو یا نہ ہو۔ یہ صارف کی سرگرمیوں کا مکمل آڈٹ ریکارڈ فراہم کرتا ہے اور ہمیں یہ واضح طور پر بتانے کے قابل بناتا ہے کہ ہم نے کریڈٹس کیوں وصول کیے یا کیوں وصول نہیں کیے۔
• ہر ایونٹ کے ساتھ ایک مستحکم آئیڈیم پوٹنسی کی (idempotency key) منسلک ہوتی ہے، تاکہ دوبارہ کوششیں (retries)، ری پلے (replays)، یا ورکر کے دوبارہ شروع ہونے کی صورت میں بھی بیلنس سے رقم دو بار نہ کٹے—اور یوں ڈبل چارجنگ سے بچاؤ ممکن ہو جاتا ہے۔ یہ ہمیں آف لائن انداز میں بیچ ریکنسیلی ایشن (batch reconciliation) چلانے کی سہولت بھی دیتا ہے تاکہ ہم اپنے کام کی درستگی کی الگ سے تصدیق کر سکیں۔
• ہم آڈٹ ٹریل بنانے کے لیے ہم وقتی (synchronous) اپ ڈیٹس کے بجائے غیر ہم وقتی (مگر پھر بھی ریئل ٹائم سے قریب) بیلنس اپڈیٹس کرتے ہیں۔ ہم صارف کے بیلنس کی اپ ڈیٹس میں معمولی سی تاخیر اِس لیے کرتے ہیں تاکہ یہ یقینی بنا سکیں کہ نظام درست طور پر کام کر رہا ہے اور صارفین کو یقین دلا سکیں کہ ہم ان سے غلط بلنگ نہیں کر رہے۔ جب اس مختصر تاخیر کے باعث صارف کے کریڈٹ بیلنس سے کچھ زیادہ کٹوتی ہو جاتی ہے تو ہم خودکار طور پر رقم واپس کر دیتے ہیں؛ ہم سخت نفاذ کے بجائے قابلِ تصدیق درستگی اور صارف کے اعتماد کو ترجیح دیتے ہیں۔
• ہم کریڈٹ بیلنس کو کم کرتے ہیں اور ایک واحد ایٹمی ڈیٹابیس ٹرانزیکشن میں بیلنس اپڈیٹ کا ریکارڈ داخل کرتے ہیں۔ بیلنس اپ ڈیٹس ہر اکاؤنٹ کے لیے سلسلہ وار کی جاتی ہیں، اس لیے بیک وقت آنے والی درخواستیں کبھی بھی ایک ہی کریڈٹس کو خرچ کرنے کے لیے مقابلہ نہیں کر سکتیں۔ بیلنس اپ ڈیٹ ریکارڈ میں ڈیبٹ رقم کے ساتھ ساتھ اس مالیاتی ایونٹ کی طرف نسبت بھی شامل ہوتی ہے جس نے اپ ڈیٹ کو متحرک کیا؛ اسے ایک ہی ڈیٹابیس ٹرانزیکشن میں رکھنے سے یہ ضمانت ملتی ہے کہ کریڈٹ بیلنس میں ہر ایڈجسٹمنٹ کے لیے ہمارے پاس ایک آڈٹ ٹریل موجود ہے۔

یہ ساری جددوجہد ایک ہی مقصد کی خاطر ہے: یعنی ایکسیس کو سادہ، محفوظ اور قابلِ اعتماد بنانا۔ جب لوگ تخلیق کر رہے ہوں یا کوڈ لکھ رہے ہوں تو انہیں یہ سوچنے کی ضرورت نہیں ہونی چاہیے کہ آیا ان کی درخواست منظور ہوگی یا نہیں، کہیں ان سے زیادہ رقم تو نہیں چارج کی جائے گی، یا ان کا بیلنس درست ہے یا نہیں۔ استعمال، بلنگ، اور بیلنس کو قابلِ تصدیق طور پر درست بنا کر ہم صارفین کو ایسا نظام فراہم کرتے ہیں جو ان کے تجربے کو متاثر نہیں کرتا۔ یہی چیز ہمیں سخت رکاوٹوں (hard stops) کی جگہ مسلسل رسائی فراہم کرنے کے قابل بناتی ہے—اور یہی کریڈٹس کو حقیقی کام کے دوران قابلِ استعمال بناتی ہے، نہ کہ صرف بل یا انوائس تک محدود رکھتی ہے۔

ہمارے طریقِ کار کے پیچھے بنیادی رہنما اصول صارف کی رفتار اور تسلسل (momentum) کو محفوظ رکھنا ہے۔ ہمارا ہر تعمیراتی (architectural) فیصلہ براہِ راست صارف کے تجربے سے جڑا ہوتا ہے: حقیقی وقت کے بیلنس غیر ضروری رکاوٹوں سے بچاتے ہیں، ایٹامک کھپت (atomic consumption) دوہری کٹوتی کو روکتی ہے، اور متحد رسائی منطق (unified access logic) قابلِ پیش گوئی اور یکساں رویّہ یقینی بناتی ہے۔ نتیجہ یہ ہے کہ لوگ زیادہ دیر تک کام کر سکتے ہیں، مزید گہرائی سے جائزہ لے سکتے ہیں، اور سخت رکاوٹوں یا قبل از وقت منصوبہ بندی میں تبدیلیوں کا سامنا کیے بغیر منصوبوں کو مزید آگے بڑھا سکتے ہیں۔

جب صارفین مشغول ہوں، تو سسٹم کو انہیں آگے بڑھنے میں مدد دینی چاہیے، نہ کہ ان کے راستے میں رکاوٹ بنے۔ لیمٹس اور کریڈٹس بیک گراؤنڈ میں غائب ہو جاتے ہیں.

اس تجربے کی تعمیر کے لیے ایکسیس ، استعمال، اور بلنگ کو ایک واحد نظام کے طور پر ازسرِنو سوچنا اور ایسا بنیادی ڈھانچہ بنانا ضروری تھا جو درستگی کو ایک اعلیٰ درجے کی پروڈکٹ فیچر کے طور پر برتتا ہو۔ وہی بنیاد وقت کے ساتھ مزید مصنوعات تک پھیل سکتی ہے؛ Codex اور Sora تو صرف آغاز ہیں۔