ব্যবহারের সীমা

১ মে, ২০২৬ থেকে এই API-এর ব্যবহারের সীমা আপডেট করা হয়েছে। যেসব Google Cloud প্রোজেক্ট নভেম্বর ২০২৫ থেকে এপ্রিল ২০২৬-এর মধ্যে এই API ব্যবহার করেছে, সেগুলি আগে থেকে সেট করা ব্যবহার কোটা অনুযায়ী কাজ করতে থাকবে। ১ মে, ২০২৬ বা তার পরে তৈরি করা ক্লাউড প্রোজেক্টের ক্ষেত্রে নতুন API কোটা প্রযোজ্য হবে।

টাইমলাইন সহ আরও তথ্যের জন্য, এজেন্ট টুল ও API-এর জন্য Google Workspace-এর স্ট্যান্ডার্ডাইজড মডেল দেখুন।

সম্পূর্ণ ঘোষণা দেখতে, Google Workspace ডেভেলপারদের জন্য এজেন্ট টুল ও নিরাপত্তা আপডেট দেখুন।

সব ব্যবহারকারী যাতে Google Calendar API সঠিকভাবে ব্যবহার করতে পারেন তা নিশ্চিত করতে কোটা আছে। Calendar API ব্যবহার করার সময় তিনটি গুরুত্বপূর্ণ সীমাবদ্ধতা বিবেচনা করতে হবে:

• API ব্যবহারের কোটা: প্রোজেক্ট ও ব্যবহারকারী প্রতি এনফোর্স করা হয়। আরও তথ্যের জন্য, Calendar API ব্যবহারের কোটার ধরন দেখুন।

• Google Calendar ব্যবহারের সাধারণ সীমা: Google Calendar API হল একটি শেয়ার করা পরিষেবা যার উপর Google Workspace সিস্টেমের সামগ্রিক পারফর্ম্যান্স সুরক্ষিত রাখার জন্য সীমাবদ্ধতা আরোপ করা হয়েছে। আরও তথ্যের জন্য, ক্যালেন্ডার ব্যবহারের সীমা এড়িয়ে চলুন দেখুন

• অপারেশনাল সীমা: এই সীমা যেকোনও সময় সীমিত করা হতে পারে। যেমন, আপনি যদি খুব দ্রুত একটি ক্যালেন্ডারে একাধিক ইভেন্ট যোগ করার চেষ্টা করেন।

Calendar API কোটা

দুই ধরনের কোটা এনফোর্স করা হয়:

• প্রতি মিনিটে প্রতি প্রোজেক্ট: এটি হল আপনার Google Cloud প্রোজেক্ট এক মিনিটে যতগুলি অনুরোধ করতে পারে তার সংখ্যা।

• প্রতি মিনিটে প্রতি ব্যবহারকারী প্রতি প্রোজেক্ট: এটি হল আপনার ক্লাউড প্রোজেক্টে কোনও একজন নির্দিষ্ট ব্যবহারকারীর করা অনুরোধের সংখ্যা। এই সীমা নির্ধারণের উদ্দেশ্য হল আপনার ব্যবহারকারীদের মধ্যে ব্যবহারের ন্যায্য বন্টন নিশ্চিত করতে আপনাকে সাহায্য করা।

স্লাইডিং উইন্ডো ব্যবহার করে প্রতি মিনিটে কোটা গণনা করা হয়। এক মিনিটে আপনার প্রতি মিনিটের কোটা অতিক্রম করে ট্রাফিকের দ্রুত বৃদ্ধি হলে, পরবর্তী উইন্ডোতে রেট সীমিত করা হবে যাতে, গড়ে, আপনার ব্যবহার কোটার মধ্যে থাকে।

এইসব সীমা সম্পর্কে নিম্নলিখিত সারণীতে বিস্তারিত বিবরণ দেওয়া হয়েছে:

ব্যবহারের সীমার ধরন	সীমা
প্রতি প্রোজেক্টে প্রতি মিনিটে	১০,০০০টি অনুরোধ
প্রতি মিনিটে প্রতি ব্যবহারকারী প্রতি প্রোজেক্ট	৬০০টি অনুরোধ

দৈনিক বিলিং থ্রেশহোল্ড

এই প্রতিদিন প্রতি প্রোজেক্ট সীমা আপনার Google Cloud প্রোজেক্টের জন্য ২৪ ঘণ্টার মধ্যে চার্জ প্রযোজ্য হওয়ার আগে সর্বাধিক কতগুলি অনুরোধ ব্যবহার করতে পারে তা নির্ধারণ করে।

এই থ্রেশহোল্ডের নিচে ব্যবহার করলে অতিরিক্ত চার্জ দিতে হয় না এবং আপনার Google Cloud অ্যাকাউন্টে বিল করা হয় না। বিলিং সংক্রান্ত সম্পূর্ণ বিবরণ ২০২৬ সালের শেষের দিকে শেয়ার করা হবে এবং কোনও পরিবর্তন কার্যকর হওয়ার অন্তত ৯০ দিন আগে বিজ্ঞপ্তি দেওয়া হবে।

আপনি এই দৈনিক থ্রেশহোল্ড সীমা বাড়ানোর অনুরোধ করতে পারবেন না।

নিচের সারণীতে সীমা সম্পর্কে বিস্তারিত বিবরণ দেওয়া হয়েছে:

থ্রেশহোল্ডের সীমার ধরন	সীমা
প্রতিদিন প্রোজেক্ট পিছু	১,০০০,০০০টি অনুরোধ

আরও তথ্যের জন্য, এজেন্ট টুল ও API-এর জন্য Google Workspace-এর স্ট্যান্ডার্ডাইজড মডেল দেখুন।

সময়-ভিত্তিক কোটা সংক্রান্ত সমস্যার সমাধান করা

সময়-ভিত্তিক সব সমস্যার (X মিনিটে সর্বাধিক N অনুরোধ) জন্য, আমরা সাজেস্ট করি যে আপনার কোড যেন ব্যতিক্রমটি ধরে এবং আপনার ডিভাইস যাতে অতিরিক্ত লোড জেনারেট না করে তা নিশ্চিত করতে ট্রাঙ্কেট করা এক্সপোনেনশিয়াল ব্যাকঅফ ব্যবহার করে।

এক্সপোনেনশিয়াল ব্যাকঅফ হল নেটওয়ার্ক অ্যাপ্লিকেশনের জন্য একটি স্ট্যান্ডার্ড এরর হ্যান্ডলিং স্ট্র্যাটেজি। An এক্সপোনেনশিয়াল ব্যাকঅফ অ্যালগরিদম, অনুরোধের মধ্যে এক্সপোনেনশিয়ালি ক্রমবর্ধমান অপেক্ষার সময় ব্যবহার করে অনুরোধ আবার চেষ্টা করে, সর্বাধিক ব্যাকঅফ সময় পর্যন্ত। অনুরোধ এখনও সম্পূর্ণ না হলে, অনুরোধ সম্পূর্ণ না হওয়া পর্যন্ত অনুরোধের মধ্যে সময়ের ব্যবধান বাড়ানো গুরুত্বপূর্ণ।

উদাহরণ অ্যালগরিদম

এক্সপোনেনশিয়াল ব্যাকঅফ অ্যালগরিদম এক্সপোনেনশিয়ালি অনুরোধ আবার করার চেষ্টা করে, আবার চেষ্টা করার মধ্যে অপেক্ষার সময় সর্বাধিক ব্যাকঅফ সময় পর্যন্ত বাড়ায়। যেমন:

1. Google Calendar API-তে অনুরোধ করুন।
2. অনুরোধটি ব্যর্থ হলে, ১ + random_number_milliseconds অপেক্ষা করুন এবং অনুরোধটি আবার চেষ্টা করুন।
3. অনুরোধটি ব্যর্থ হলে, ২ + random_number_milliseconds অপেক্ষা করুন এবং অনুরোধটি আবার চেষ্টা করুন।
4. অনুরোধটি ব্যর্থ হলে, 4 + random_number_milliseconds অপেক্ষা করুন এবং অনুরোধটি আবার চেষ্টা করুন।
5. এবং এইভাবে maximum_backoff বার পর্যন্ত।
6. সর্বাধিক যতবার চেষ্টা করা যায় ততবার চেষ্টা করা চালিয়ে যান, তবে চেষ্টা করার মধ্যেকার অপেক্ষার সময় বাড়িয়ে দেবেন না।

কোথায়:

• অপেক্ষা করার সময় হল min(((2^n)+random_number_milliseconds), maximum_backoff), প্রতিটি ইটারেশনের (অনুরোধ) জন্য n ১ করে বাড়ানো হয়।
• random_number_milliseconds হল ১,০০০-এর থেকে কম বা সমান মিলি সেকেন্ডের একটি র‍্যান্ডম সংখ্যা। এটি এমন পরিস্থিতি এড়াতে সাহায্য করে যেখানে অনেক ক্লায়েন্ট কোনও পরিস্থিতির কারণে সিঙ্ক্রোনাইজ হয় এবং সবাই একসাথে আবার চেষ্টা করে, সিঙ্ক্রোনাইজড ওয়েভে অনুরোধ পাঠায়। প্রতিবার আবার চেষ্টা করার অনুরোধের পরে random_number_milliseconds-এর ভ্যালু আবার গণনা করা হয়।
• maximum_backoff সাধারণত ৩২ বা ৬৪ সেকেন্ডের হয়। ব্যবহারের উপর নির্ভর করে উপযুক্ত ভ্যালু নির্ধারণ করা হয়।

maximum_backoff বার চেষ্টা করার পরেও ক্লায়েন্ট আবার চেষ্টা করা চালিয়ে যেতে পারে। এই পয়েন্টের পরে আবার চেষ্টা করার জন্য ব্যাকঅফ টাইম বাড়ানো চালিয়ে যাওয়ার প্রয়োজন নেই। যেমন, কোনও ক্লায়েন্ট যদি ৬৪ সেকেন্ডের maximum_backoff টাইম ব্যবহার করে, তাহলে এই ভ্যালুতে পৌঁছানোর পরে, ক্লায়েন্ট প্রতি ৬৪ সেকেন্ডে আবার চেষ্টা করতে পারবে। কোনও এক সময়, ক্লায়েন্টদের অনির্দিষ্টকাল ধরে আবার চেষ্টা করা থেকে বিরত রাখতে হবে।

আবার চেষ্টা করার মধ্যে অপেক্ষার সময় এবং কতবার আবার চেষ্টা করা হবে তা আপনার ব্যবহারের ক্ষেত্র এবং নেটওয়ার্কের অবস্থার উপর নির্ভর করে।

দাম

Google Calendar API-এর সব স্ট্যান্ডার্ড ব্যবহার কোনও অতিরিক্ত খরচ ছাড়াই উপলভ্য। কোটা অনুরোধের সীমা অতিক্রম করলে, ২০২৬ সালের শেষের দিকে আপনার Google Cloud বিলিং অ্যাকাউন্টে চার্জ করা হবে। আরও তথ্যের জন্য, এজেন্ট টুল ও API-এর জন্য Google Workspace-এর স্ট্যান্ডার্ডাইজড মডেল দেখুন।

কোটা বাড়ানোর অনুরোধ করা

আপনার প্রোজেক্টের রিসোর্স ব্যবহারের উপর নির্ভর করে, আপনি কোটা অ্যাডজাস্ট করার জন্য অনুরোধ করতে পারেন। পরিষেবা অ্যাকাউন্টের মাধ্যমে API কলকে একটি অ্যাকাউন্ট ব্যবহার করা হচ্ছে বলে বিবেচনা করা হয়। অ্যাডজাস্ট করা কোটার জন্য আবেদন করলেই যে অনুমোদন পাওয়া যাবে, তার কোনও গ্যারেন্টি নেই। কোটা অ্যাডজাস্টমেন্টের অনুরোধের ফলে কোটার ভ্যালু উল্লেখযোগ্যভাবে বৃদ্ধি পেলে, তা অনুমোদন করতে বেশি সময় লাগতে পারে।

সব প্রোজেক্টের কোটা এক নয়। সময়ের সাথে সাথে আপনি Google Cloud-এর ব্যবহার বাড়িয়ে দিলে, আপনার কোটার ভ্যালুও বাড়াতে হতে পারে। আপনি যদি আশা করেন যে আগামী দিনে ব্যবহার উল্লেখযোগ্যভাবে বৃদ্ধি পাবে, তাহলে আপনি Google Cloud কনসোলের কোটা ও সিস্টেমের সীমা পৃষ্ঠা থেকে কোটা অ্যাডজাস্ট করার অনুরোধ করতে পারেন।

আরও জানতে, নিম্নলিখিত রিসোর্স দেখুন:

• কোটা অ্যাডজাস্টমেন্ট সম্পর্কে
• আপনার কোটার ব্যবহার ও সীমা দেখুন
• আরও বেশি কোটা সীমার জন্য অনুরোধ করুন

সমস্যার সমাধান করুন

কোনও কোটা অতিক্রম করলে, আপনার রেট সীমিত করা হয় এবং আপনার কোয়েরির উত্তরে আপনি একটি 403 usageLimits স্ট্যাটাস কোড বা একটি 429 usageLimits স্ট্যাটাস কোড পাবেন।

এমন হলে, আপনি নিম্নলিখিত ধাপগুলি অনুসরণ করতে পারেন:

1. সব পেশাদার পদ্ধতি অনুসরণ করতে ভুলবেন না: এক্সপোনেনশিয়াল ব্যাকঅফ, র‍্যান্ডমাইজ ট্রাফিক প্যাটার্ন এবং পুশ বিজ্ঞপ্তি ব্যবহার করুন।

2. আপনার প্রোজেক্টের পরিধি বৃদ্ধি পেলে এবং ব্যবহারকারীর সংখ্যা বাড়লে, আপনি কোটা বাড়ানোর অনুরোধ করতে পারেন।

3. আপনি ব্যবহারকারী প্রতি কোটার সীমায় পৌঁছে গেলে, নিম্নলিখিত কাজগুলি করতে পারেন:

   • আপনি কোনও পরিষেবা অ্যাকাউন্ট ব্যবহার করলে, ব্যবহারকারীদের মধ্যে লোড বরাদ্দ করুন অথবা একাধিক পরিষেবা অ্যাকাউন্টের মধ্যে এটি ভাগ করুন।

   • আপনি ব্যবহারকারী প্রতি কোটা বাড়ানোর অনুরোধ করতে পারেন, তবে সাধারণত, ডিফল্ট ভ্যালুর উপরে এটি বাড়ানোর সাজেশন দেওয়া হয় না কারণ আপনার অ্যাপ্লিকেশন অন্যান্য ধরনের সীমা অতিক্রম করতে শুরু করতে পারে, যেমন, সাধারণ ক্যালেন্ডার ব্যবহারের সীমা বা অপারেশনাল সীমা।

4. আপনার প্রোডাকশন প্রোজেক্টের মতো একই কনফিগারেশন আছে এমন একটি আলাদা টেস্ট-অনলি প্রোজেক্ট রেজিস্টার করে আপনার কোটা সীমা পরীক্ষা করুন। আরও তথ্যের জন্য, কোটা সীমা হ্যান্ডেল করা পরীক্ষা করুন দেখুন।

ট্রাফিক প্যাটার্ন র‍্যান্ডমাইজ করুন

একাধিক ক্লায়েন্ট একই সময়ে অপারেশন পারফর্ম করার কারণে Calendar ক্লায়েন্টদের ট্রাফিক প্যাটার্নে স্পাইক দেখা যায়। যেমন, Calendar ক্লায়েন্টের ক্ষেত্রে একটি সাধারণ খারাপ অভ্যাস হল মধ্যরাতে সম্পূর্ণ সিঙ্ক করা। এর ফলে আপনার প্রতি মিনিটের কোটা প্রায় নিশ্চিতভাবেই পেরিয়ে যাবে এবং রেট লিমিটিং ও ব্যাকঅফ হবে।

এটি এড়াতে, আপনার ট্রাফিক যাতে সারাদিন ধরে ছড়িয়ে থাকে তা নিশ্চিত করুন, যেখানেই সম্ভব। আপনার ক্লায়েন্টকে প্রতিদিন সিঙ্ক করতে হলে, ক্লায়েন্টকে একটি র‍্যান্ডম সময় (প্রতিটি ক্লায়েন্টের জন্য আলাদা) নির্ধারণ করতে বলুন। আপনাকে নিয়মিত কোনও অপারেশন করতে হলে, সময়ের ব্যবধান +/- ২৫% পরিবর্তন করুন। এটি ট্রাফিককে আরও সমানভাবে বিতরণ করবে এবং ব্যবহারকারীকে আরও ভালো অভিজ্ঞতা প্রদান করবে।

পুশ বিজ্ঞপ্তি ব্যবহার করুন

ব্যবহারকারীর ক্যালেন্ডারে কোনও পরিবর্তন হলে, কোনও অ্যাকশন পারফর্ম করা হল একটি সাধারণ ব্যবহারিক উদাহরণ। এখানে একটি অ্যান্টি-প্যাটার্ন হল আগ্রহের প্রতিটি ক্যালেন্ডার বারবার পোল করা। এর ফলে আপনার কোটা খুব দ্রুত শেষ হয়ে যাবে। যেমন, আপনার অ্যাপ্লিকেশনে যদি ৫,০০০ ব্যবহারকারী থাকেন এবং প্রতি মিনিটে প্রত্যেক ব্যবহারকারীর ক্যালেন্ডার পোল করা হয়, তাহলে কোনও কাজ করার আগেই প্রতি মিনিটে অন্তত ৫,০০০ কোটার প্রয়োজন হবে।

সার্ভার-সাইড অ্যাপ্লিকেশন পুশ বিজ্ঞপ্তির জন্য রেজিস্টার করতে পারে, যা আমাদের আপনার আগ্রহের কিছু ঘটলে আপনাকে জানানোর অনুমতি দেয়। এগুলি সেট-আপ করতে আরও বেশি কাজ করতে হয়, তবে আপনার কোটার নাটকীয়ভাবে আরও দক্ষ ব্যবহারের অনুমতি দেয় এবং আরও ভালো ব্যবহারকারীর অভিজ্ঞতা প্রদান করে। আপনি যে eventType-এর জন্য বিজ্ঞপ্তি পেতে চান সেটি উল্লেখ করতে ভুলবেন না। আরও তথ্যের জন্য, পুশ বিজ্ঞপ্তি দেখুন।

পরিষেবা অ্যাকাউন্টের সাথে সঠিক বরাদ্দকরণ

আপনার অ্যাপ্লিকেশন ডোমেন-ওয়াইড প্রতিনিধিত্ব ব্যবহার করে অনুরোধ করলে, ডিফল্ট হিসেবে পরিষেবা অ্যাকাউন্ট "প্রতি মিনিট প্রতি ব্যবহারকারী প্রতি প্রজেক্ট" কোটা অনুযায়ী চার্জ করা হয়, আপনি যে ব্যবহারকারীর ছদ্মবেশ ধারণ করছেন তার জন্য নয়। এর অর্থ হল, পরিষেবা অ্যাকাউন্টের কোটা শেষ হয়ে যেতে পারে এবং রেট-লিমিট করা হতে পারে, যদিও এটি একাধিক ব্যবহারকারীর ক্যালেন্ডারে কাজ করতে পারে।

আপনি quotaUser URL প্যারামিটার (বা x-goog-quota-user HTTP হেডার) ব্যবহার করে এটি এড়াতে পারেন, যাতে প্রতিটি স্বতন্ত্র ব্যবহারকারীকে অনন্যভাবে শনাক্ত করে এমন একটি ইচ্ছামতো স্ট্রিং (৪০টি অক্ষর পর্যন্ত) নির্দিষ্ট করা যায়। Calendar API শুধুমাত্র কোটা গণনা করার জন্য এই মান ব্যবহার করে।

quotaUser ব্যবহার করে বিভিন্ন ব্যবহারকারীর জন্য আলাদা আলাদা রেট লিমিট প্রয়োগ করতে, আপনার অনুরোধকে নিম্নলিখিত প্রয়োজনীয়তা পূরণ করতে হবে:

• IP-সীমাবদ্ধ API কী অন্তর্ভুক্ত করুন: key কোয়েরি প্যারামিটারে একটি API কী পাস করুন এবং আপনার ব্যাকএন্ড সার্ভারের পাবলিক IP অ্যাড্রেস উল্লেখ করে IP অ্যাড্রেস সীমাবদ্ধতা সহ সেই কী কনফিগার করুন। আপনি API কী বাদ দিলে বা IP অ্যাড্রেস সংক্রান্ত বিধিনিষেধ কনফিগার না করলে, Calendar API quotaUser উপেক্ষা করে এবং যাচাই করা অ্যাকাউন্টে (যেমন, পরিষেবা অ্যাকাউন্ট) কোটা চার্জ করে।

• X-Goog-User-Project হেডার বাদ দিন: quotaUser ব্যবহার করে এমন অনুরোধে X-Goog-User-Project HTTP হেডার পাঠাবেন না। ব্যবহারকারীর প্রোজেক্ট প্রদান করলে কোটা অ্যাট্রিবিউশনের জন্য API কী ওভাররাইড হয়ে যায়, তাই Calendar API quotaUser উপেক্ষা করে।

আরও তথ্যের জন্য, ব্যবহারকারী প্রতি অনুরোধের সংখ্যা সীমিত করা দেখুন।

কোটার সীমা ম্যানেজ করার বিষয়টি পরীক্ষা করুন

আপনার অ্যাপ্লিকেশন যাতে কোটা সীমায় পৌঁছানোর বিষয়টি বাস্তবে (যেমন, এক্সপোনেনশিয়াল ব্যাকঅফ সহ আবার চেষ্টা করার মাধ্যমে) সুন্দরভাবে ম্যানেজ করতে পারে এবং আপনার ব্যবহারকারীদের সম্ভাব্য অসুবিধা যতটা সম্ভব কমাতে পারে, তা নিশ্চিত করতে, আমরা আপনাকে বাস্তব পরিবেশে আপনার পরিস্থিতি পরীক্ষা করার জন্য জোরালোভাবে সাজেস্ট করি।

আপনার আসল অ্যাপ্লিকেশন ব্যবহারে কোনও বাধা না দিয়ে পরীক্ষা করতে, আমরা সাজেস্ট করি যে Google Cloud কনসোলে আলাদা একটি শুধু-পরীক্ষার প্রোজেক্ট রেজিস্টার করুন এবং তারপর আপনার প্রোডাকশন প্রোজেক্টের মতো করে OAuth-এর সম্মতি সংক্রান্ত স্ক্রিন কনফিগার করুন। তারপর আপনি এই প্রোজেক্টের জন্য কৃত্রিমভাবে কম কোটা সীমা সেট করতে এবং আপনার অ্যাপ্লিকেশনের আচরণ পর্যবেক্ষণ করতে পারবেন।

Calendar MCP সার্ভার কোটা

Calendar MCP সার্ভার কোয়েরি খরচ বরাদ্দকরণ মেট্রিক ব্যবহার করে। নিম্নলিখিত সারণীতে প্রতিটি Calendar MCP সার্ভার পদ্ধতির জন্য কোয়েরি খরচ বিভাগ অনুসারে বিস্তারিতভাবে দেখানো হয়েছে:

Calendar MCP কোটা

দুই ধরনের কোটা এনফোর্স করা হয়:

• প্রতি মিনিটে প্রতি প্রোজেক্টে: এটি হল এক মিনিটের জন্য আপনার Google Cloud প্রোজেক্টে কোয়েরির খরচ।

• প্রতি মিনিটে প্রতি ব্যবহারকারী প্রতি প্রোজেক্ট: এটি হল আপনার Google Cloud প্রোজেক্টের জন্য এক মিনিটের কোয়েরি খরচ যা যেকোনও একজন নির্দিষ্ট ব্যবহারকারী ব্যবহার করতে পারবেন।

নিম্নলিখিত সারণীতে এই কোটার বিবরণ দেওয়া হয়েছে:

ব্যবহারের সীমার ধরন	কোয়েরির খরচ
প্রতি প্রোজেক্টে প্রতি মিনিটে	১০,০০০
প্রতি মিনিটে প্রতি ব্যবহারকারী প্রতি প্রোজেক্ট	600

Calendar MCP টুলসেট কোটা

নিম্নলিখিত সারণীতে প্রতিটি calendarmcp.googleapis.com টুলসেটের জন্য কোয়েরি খরচের বিবরণ দেওয়া হয়েছে:

এন্ডপয়েন্ট	টুল	কোয়েরির খরচ
/mcp/v1	create_event	1
	delete_event	10
	get_event	1
	list_events	1
	respond_to_event	1
	search_events	1
	update_event	1
	suggest_time	1
	list_calendars	1

আরও তথ্যের জন্য, Calendar MCP API Reference দেখুন।

সম্পর্কিত বিষয়

• ব্যাচ অনুরোধ পাঠান
• পারফর্ম্যান্স সংক্রান্ত পরামর্শ
• Calendar ব্যবহারের সীমা এড়িয়ে চলুন