রেট সীমার বাইরে: Codex এবং Sora-তে অ্যাক্সেস বাড়ানো

গত এক বছরে, Codex এবং Sora উভয়ই দ্রুত গ্রহণযোগ্যতা পেয়েছে এবং তাদের ব্যবহার আমাদের মূল প্রত্যাশার চেয়ে দ্রুত বৃদ্ধি পেয়েছে. আমরা একটি ধারাবাহিক প্যাটার্ন লক্ষ্য করেছি: ব্যবহারকারীরা শুরুতেই প্রবেশ করে, প্রকৃত মূল্য খুঁজে পায় এবং তারপর রেট সীমায় আটকে যায়.

রেট সীমা চাহিদা মসৃণ করতে এবং ন্যায্য অ্যাক্সেস নিশ্চিত করতে সহায়ক হতে পারে; তবে, যখন ব্যবহারকারীরা সুবিধা পাচ্ছেন, তখন একটি কঠোর সীমায় পৌঁছানো হতাশাজনক হতে পারে. আমরা চেয়েছিলাম ব্যবহারকারীরা যেন এগিয়ে যেতে পারে, একইসাথে সিস্টেমের কর্মক্ষমতা এবং আমাদের পদ্ধতির প্রতি ব্যবহারকারীদের আস্থা রক্ষা করা যায়.

এটি সমাধান করতে, আমরা একটি রিয়েল-টাইম অ্যাক্সেস ইঞ্জিন তৈরি করেছি যা ব্যবহার গণনা করে. ঐ ইঞ্জিনের একটি স্তর হলো ক্রেডিট কেনার ক্ষমতা. যখন ব্যবহারকারীরা তাদের রেট সীমা অতিক্রম করে, তখন ক্রেডিট তাদের ক্রেডিট ব্যালান্স থেকে খরচ করে আমাদের পণ্যগুলি ব্যবহার চালিয়ে যেতে সহায়তা করে.

এর নিচে একটি জটিল সিস্টেম রয়েছে যা সীমাবদ্ধতা, রিয়েল-টাইম ব্যবহার ট্র্যাকিং এবং ক্রেডিট ব্যালান্সকে একক মডেল অ্যাক্সেসে একত্রিত করে. এই পোস্টে আলোচনা করা হয়েছে কেন Codex এবং Sora-এর স্কেলিংয়ের জন্য অ্যাক্সেস নিয়ন্ত্রণ পুনর্বিবেচনা করতে হয়েছিল, কিভাবে একটি প্রমাণযোগ্যভাবে সঠিক, রিয়েল-টাইম সিস্টেম প্রতি অনুরোধে রেট সীমা এবং ক্রেডিট মিশ্রিত করে এবং কিভাবে সেই ভিত্তি এখন উভয় পণ্যের জন্য অতিরিক্ত অ্যাক্সেস উন্মুক্ত করছে.

বৃহত্তর পরিপ্রেক্ষিতে, ঐতিহ্যবাহী অ্যাক্সেস মডেলগুলো সাধারণত একটি সিদ্ধান্ত নিতে বাধ্য করে:

• রেট লিমিট শুরুতে সহায়ক হতে পারে, কিন্তু যখন এর সীমা শেষ হয়ে যায়, তখন ব্যবহারকারীদের একটি খারাপ অভিজ্ঞতার সম্মুখীন হতে হয়: 'পরে আবার চেষ্টা করুন”
• ব্যবহার-ভিত্তিক বিলিং নমনীয়, তবে এটি ব্যবহারকারীদের প্রথম টোকেন থেকেই অর্থ প্রদান করতে বাধ্য করে—যা প্রাথমিক অনুসন্ধানের জন্য আদর্শ নয়

Codex এবং Sora-এর জন্য, কোনোটিই একা যথেষ্ট ছিল না. যদি আমরা কেবল রেট সীমা বাড়াতাম, তাহলে আমরা চাহিদা-সমতলকরণ এবং ন্যায্যতা নিয়ন্ত্রণের গুরুত্বপূর্ণ দিকগুলো হারাতাম এবং সবার জন্য সেবা দেওয়ার ক্ষমতা ফুরিয়ে যেত. যদি আমরা সম্পূর্ণভাবে অ্যাসিঙ্ক্রোনাস ইউসেজ বিলিংয়ের উপর নির্ভর করতাম, তাহলে আমরা ল্যাগ, ওভারেজ বা সমন্বয় সমস্যার সৃষ্টি করতাম—ঠিক সেই ধরনের সমস্যা, যেগুলো ব্যবহারকারীরা সবচেয়ে বেশি জড়িত থাকলে লক্ষ্য করে.

আমাদের যা দরকার ছিল তা হলো রিয়েল-টাইম সীমা এবং পে-অ্যাজ-ইউ-গো অ্যাক্সেস একত্রিত করে এমন একটি একক হাইব্রিড সিস্টেম:

এই সিস্টেমটিকে যা করতে হতো:

• রেট লিমিট যতক্ষণ না সেগুলোতে পৌঁছানো হয় ততক্ষণ প্রয়োগ করুন
• একই অনুরোধের মধ্যেইক্রেডিটে নিরবিচ্ছিন্নভাবে রূপান্তর করুন
• রিয়েল-টাইমে সেই সিদ্ধান্ত নিন
• ক্রেডিট ব্যবহারের হিসাব রাখার সময় নির্ভুলতা এবং অডিটযোগ্যতা নিশ্চিত করুন

আমরা যে প্রধান ধারণাগত পরিবর্তনগুলির একটি করেছি তা হলো অ্যাক্সেসকে একটি সিদ্ধান্ত জলপ্রপাত হিসেবে মডেল করা. “এটা অনুমোদিত কি না” জিজ্ঞাসা করার পরিবর্তে, আমরা জিজ্ঞাসা করি “কতটা অনুমোদিত এবং কোথা থেকে?” ব্যবহারের হিসাব করার সময়, সিস্টেম নিম্নলিখিত ক্রম অনুসরণ করে:

এই মডেলটি প্রতিফলিত করে ব্যবহারকারীরা বাস্তবে কিভাবে পণ্যটি ব্যবহার করেন. রেট লিমিট, ফ্রি টিয়ার, ক্রেডিট, প্রোমোশন এবং এন্টারপ্রাইজ এনটাইটেলমেন্ট—সবই একই সিদ্ধান্ত স্তরের অংশ. একজন ব্যবহারকারীর দৃষ্টিকোণ থেকে, তারা “সিস্টেম পরিবর্তন করে না”—তারা শুধু Codex এবং Sora ব্যবহার করতে থাকে. এ কারণেই ক্রেডিটগুলো অদৃশ্য মনে হয়: এগুলো কেবল জলপ্রপাতের আরেকটি উপাদান.

আমরা ক্রেডিট খরচ পরিচালনার জন্য তৃতীয় পক্ষের ব্যবহার বিলিং এবং মিটারিং প্ল্যাটফর্মগুলি মূল্যায়ন করেছি. এগুলো ইনভয়েসিং এবং রিপোর্টিংয়ের জন্য ভালোভাবে উপযুক্ত, কিন্তু দুটি গুরুত্বপূর্ণ প্রয়োজনীয়তা পূরণ করতে পারেনি:

যখন কোনো ব্যবহারকারী সীমায় পৌঁছায় এবং ক্রেডিট উপলব্ধ থাকে, সিস্টেমকে অবিলম্বে জানতে হবে. সর্বোচ্চ প্রচেষ্টা বা বিলম্বিত গণনা অপ্রত্যাশিত ব্লক, অসামঞ্জস্যপূর্ণ ব্যালেন্স এবং ভুল চার্জ হিসেবে প্রকাশ পায়. Codex এবং Sora-এর মতো ইন্টারঅ্যাকটিভ পণ্যের জন্য, সেই ব্যর্থতাগুলো স্পষ্ট হয়ে ওঠে এবং বিরক্তিকর হয়.

আমাদের প্রতিটি ফলাফলের ক্ষেত্রে স্বচ্ছতা প্রদান করাও প্রয়োজন ছিল:

• কেন একটি অনুরোধ অনুমোদিত বা অবরুদ্ধ করা হয়েছে
• এটি কতটা ব্যবহার করেছে
• কোন সীমাবদ্ধতা বা ভারসাম্য প্রয়োগ করা হয়েছিল

এই সক্ষমতাটি আমাদের সিদ্ধান্ত গ্রহণের প্রক্রিয়ার সঙ্গে ঘনিষ্ঠভাবে একীভূত করা প্রয়োজন ছিল, আলাদা একটি ব্যবহার-বিলিং প্ল্যাটফর্মে সমাধান না করে, যা কেবল ঘটনার একটি অংশ দেখতে পেত. ব্যবহারকারীদের আস্থার সাথে আমাদের পণ্যগুলিতে অ্যাক্সেস দেওয়ার জন্য, আমাদের নির্ভুলতা, সময় নির্ধারণ এবং পর্যবেক্ষণযোগ্যতার উপর পূর্ণ নিয়ন্ত্রণ থাকা প্রয়োজন ছিল. এটি আমাদের নিজস্ব সমাধানের দিকে ঠেলে দিয়েছে.

এটি চালানোর জন্য, আমরা সিঙ্ক্রোনাস অ্যাক্সেস সিদ্ধান্তের জন্য বিশেষভাবে ডিজাইন করা একটি বিতরণকৃত ব্যবহার এবং ব্যালেন্স সিস্টেম তৈরি করেছি.

উচ্চ স্তরে, সিস্টেমটি:

• প্রত্যেক ব্যবহারকারী এবং প্রতিটি ফিচারের ব্যবহারের তথ্য ট্র্যাক করে.
• রেট সীমা উইন্ডো বজায় রাখে
• রিয়েল-টাইম ক্রেডিট ব্যালেন্স বজায় রাখে
• একটি স্ট্রিমিং অ্যাসিনক্রোনাস প্রসেসরের মাধ্যমে আইডেমপোটেন্ট পদ্ধতিতে ব্যালেন্স ডেবিট করে

প্রতিটি অনুরোধ একটি একক মূল্যায়ন পথের মধ্য দিয়ে যায় যা রিয়েল-টাইমে সিদ্ধান্ত নেয় কতটা ব্যবহার অনুমোদিত হবে, রেট লিমিট থেকে সিঙ্ক্রোনাসভাবে ব্যবহার খরচ করে এবং প্রয়োজন হলে পর্যাপ্ত ক্রেডিট যাচাই করে; এরপর এটি একটি চূড়ান্ত ফলাফল ফেরত দেয় এবং ক্রেডিট ডেবিটগুলো অ্যাসিঙ্ক্রোনাসভাবে নিষ্পত্তি করে. এটি পণ্যজুড়ে ধারাবাহিক আচরণ নিশ্চিত করে এবং দলগুলোর মধ্যে পুনরাবৃত্ত লজিক দূর করে.

এই সিস্টেমের একটি প্রধান নকশা নীতি হলো আমাদের অবশ্যই প্রমাণ করতে সক্ষম হতে হবে যে আমাদের বিলিং সঠিক. এটি আমাদের ক্রেডিট সাপোর্টের মূলকে প্রতিফলিত করে, যা এন্টারপ্রাইজ গ্রাহকদের সাথে শুরু হয়েছিল. উপরের সিস্টেম ডায়াগ্রামে, আমাদের তিনটি পৃথক ডেটাসেট রয়েছে, যেগুলো সব একসাথে সংযুক্ত হয়:

• পণ্যের ব্যবহার ইভেন্ট: ব্যবহারকারী আসলে কী করেছে
• মনিটাইজেশন ইভেন্ট: ব্যবহারকারীর ব্যবহারের জন্য আমরা যা চার্জ করি
• ব্যালান্স আপডেট: আমরা ব্যবহারকারীর ক্রেডিট ব্যালান্স কতটা পরিবর্তন করেছি এবং কেন

এই ডেটাসেটগুলো কোনো সাধারণ উপজাত নয়; এগুলো আসলে সিস্টেমকে চালিত করে, যেখানে প্রতিটি ডেটাসেট পরবর্তীটিকে সক্রিয় করে. কী ঘটেছে (ঘটনা), সংশ্লিষ্ট চার্জ এবং আমরা কত টাকা ডেবিট করেছি—এই বিষয়গুলোকে আলাদা রাখার ফলে আমরা প্রতিটি স্তর স্বতন্ত্রভাবে অডিট, রিপ্লে এবং রিকনসাইল করতে পারি. এটি একটি ইচ্ছাকৃত সমঝোতা যেখানে আমরা প্রমাণযোগ্য নির্ভুলতাকে অগ্রাধিকার দিচ্ছি, যার ফলে ক্রেডিট ব্যালান্স আপডেট সামান্য বিলম্বিত হচ্ছে. আমরা কিভাবে এটি অর্জন করেছি:

• ক্রেডিট ব্যবহারে প্রভাব ফেলুক বা না ফেলুক, সকল ব্যবহারকারীর কার্যকলাপের জন্য প্রোডাক্ট ব্যবহারের ইভেন্ট প্রকাশিত হয়. এটি ব্যবহারকারীর কার্যকলাপের জন্য একটি অডিট ট্রেইল প্রদান করে এবং কেন আমরা ক্রেডিট চার্জ করেছি বা করিনি, তা ব্যাখ্যা করতে আমাদের সক্ষম করে.
• প্রতিটি ইভেন্টে একটি স্থিতিশীল আইডেমপোটেন্সি কী থাকে, যার ফলে পুনরায় চেষ্টা, রিপ্লে বা ওয়ার্কার রিস্টার্টের কারণে কখনোই একটি ব্যালেন্স থেকে দুবার ডেবিট হতে পারে না; এটি ডাবল-চার্জিং বা দ্বিগুণ অর্থ কেটে নেওয়া রোধ করে. এটি আমাদের কাজ অফলাইনে যাচাই করার জন্য একটি ব্যাচ পুনর্মিলন চালানোর সুযোগও দেয়.
• আমরা অডিট ট্রেইল তৈরি করতে সিঙ্ক্রোনাস আপডেটের পরিবর্তে অ্যাসিঙ্ক্রোনাস (তবুও প্রায় রিয়েল-টাইম) ব্যালেন্স আপডেট করি. সিস্টেমটি সঠিকভাবে কাজ করছে তা প্রমাণ করতে এবং আমাদের ব্যবহারকারীদের আশ্বস্ত করতে যে আমরা তাদের ভুলভাবে বিল করছি না, আমরা ব্যবহারকারীর ব্যালেন্স আপডেট করতে সামান্য বিলম্ব সহ্য করি. যখন সেই সামান্য বিলম্বের কারণে আমরা কোনো ব্যবহারকারীর ক্রেডিট ব্যালেন্স অতিক্রম করি, তখন আমরা স্বয়ংক্রিয়ভাবে তা ফেরত দিই; কঠোর প্রয়োগের চেয়ে আমরা প্রমাণযোগ্য নির্ভুলতা এবং ব্যবহারকারীর আস্থাকে অগ্রাধিকার দিই.
• আমরা একটি একক অ্যাটমিক ডেটাবেস লেনদেনে ক্রেডিট ব্যালেন্স কমাই এবং একটি ব্যালেন্স আপডেট রেকর্ড সন্নিবেশ করি. প্রতি অ্যাকাউন্টে ব্যালান্স আপডেটগুলি সিরিয়ালাইজ করা হয়, তাই একাধিক অনুরোধ কখনও একই ক্রেডিট খরচ করার জন্য প্রতিযোগিতা করতে পারে না. ব্যালেন্স আপডেট রেকর্ডে ডেবিটের পরিমাণ এবং আপডেটটি যে মনিটাইজেশন ইভেন্টের কারণে ট্রিগার হয়েছে তার অ্যাট্রিবিউশন অন্তর্ভুক্ত থাকে; এটিকে একটি একক ডেটাবেস লেনদেনের মধ্যে আবদ্ধ করলে আমরা ক্রেডিট ব্যালেন্সে প্রতিটি সমন্বয়ের জন্য একটি অডিট ট্রেইল নিশ্চিত করতে পারি.

এই সমস্ত কঠোরতা একটি লক্ষ্যকে সমর্থন করে: প্রবেশাধিকারকে সহজ এবং নিরাপদ করা. মানুষ যখন তৈরি বা কোডিং করছে, তখন তাদের ভাবতে হবে না যে কোনো অনুরোধ যাবে কিনা, তাদের অতিরিক্ত চার্জ করা হবে কিনা, বা তাদের ব্যালেন্স সঠিক কিনা. ব্যবহার, বিলিং এবং ব্যালেন্সকে প্রমাণযোগ্যভাবে সঠিক করে, আমরা ব্যবহারকারীদের এমন একটি সিস্টেম প্রদান করি যা তাদের অভিজ্ঞতা থেকে মনোযোগ সরিয়ে নেয় না. এটাই আমাদের হার্ড স্টপের পরিবর্তে ধারাবাহিক অ্যাক্সেস প্রদান করে—এবং এটাই ক্রেডিটকে বাস্তব কাজের মধ্যে ব্যবহারযোগ্য করে তোলে, শুধু কোনো ইনভয়েসে নয়.

আমাদের পদ্ধতির মূল নীতি হলো ব্যবহারকারীর অগ্রগতি রক্ষা করা. প্রতিটি স্থাপত্যগত সিদ্ধান্ত ব্যবহারকারীর সামনে দৃশ্যমান একটি ফলাফলের সঙ্গে সম্পর্কিত: রিয়েল-টাইম ব্যালেন্স অপ্রয়োজনীয় বাধা প্রতিরোধ করে, অ্যাটমিক কনজাম্পশন দ্বিগুণ চার্জ হওয়া প্রতিরোধ করে, এবং একীভূত অ্যাক্সেস লজিক পূর্বানুমেয় আচরণ নিশ্চিত করে. ফলাফল হলো মানুষ আরও দীর্ঘ সময় কাজ করতে পারে, আরও গভীরভাবে অনুসন্ধান করতে পারে এবং কঠোরভাবে থেমে যাওয়া বা আগেভাগে পরিকল্পনা পরিবর্তনের মুখোমুখি না হয়েই প্রকল্পগুলোকে আরও এগিয়ে নিতে পারে.

যখন ব্যবহারকারীরা সম্পৃক্ত থাকে, তখন সিস্টেমের উচিত তাদের এগিয়ে যেতে সহায়তা করা, পথে বাধা সৃষ্টি না করা. সীমাবদ্ধতা এবং ক্রেডিট ব্যাকগ্রাউন্ডে মিলিয়ে যায়.

অভিজ্ঞতা তৈরি করতে অ্যাক্সেস, ব্যবহার এবং বিলিংকে একটি একক সিস্টেম হিসেবে পুনর্বিবেচনা করা এবং নির্ভুলতাকে প্রথম-শ্রেণির পণ্য বৈশিষ্ট্য হিসেবে বিবেচনা করে এমন অবকাঠামো তৈরি করা প্রয়োজন. একই ভিত্তি সময়ের সাথে আরও পণ্যগুলিতে প্রসারিত হতে পারে; Codex এবং Sora কেবল শুরু.