০৯ অক্টো, ২০২৫·8 মিনিট
কিভাবে AI অস্পষ্ট প্রম্পটকে প্রোডাকশন-রেডি আর্কিটেকচারে পরিণত করে
কিভাবে AI অস্পষ্ট প্রম্পটকে প্রোডাকশন-রেডি আর্কিটেকচারে রূপান্তর করে: প্রয়োজন নির্ধারণ, অনুমানসমূহ উন্মোচন, ট্রেডঅফ ম্যাপিং, ও ডিজাইন যাচাই।
কিভাবে AI অস্পষ্ট প্রম্পটকে প্রোডাকশন-রেডি আর্কিটেকচারে রূপান্তর করে: প্রয়োজন নির্ধারণ, অনুমানসমূহ উন্মোচন, ট্রেডঅফ ম্যাপিং, ও ডিজাইন যাচাই।
একটি “অস্পষ্ট প্রম্পট” সাধারণত স্বাভাবিক শুরু— কারণ বেশিরভাগ আইডিয়াই উদ্দেশ্য হিসেবে শুরু হয়, স্পেসিফিকেশন হিসেবে নয়: “কাস্টমার পোর্টাল বানান,” “AI সার্চ যোগ করুন,” বা “রিয়েল-টাইমে ইভেন্ট স্ট্রিম করুন।” মানুষ জানে তারা কী ফলাফল চায়, কিন্তু এখনও সীমানা, ঝুঁকি, বা এমন ইঞ্জিনিয়ারিং বিকল্পগুলো জানে না যা তা বাস্তবায়নযোগ্য করে।
“প্রম্পট থেকে আর্কিটেকচার” হলো সেই ওয়ার্কফ্লো যা ওই উদ্দেশ্যকে একটি সঙ্গত পরিকল্পনায় রূপান্তর করে: কী বানাবেন, উপাদানগুলো কীভাবে ফিট করবে, ডেটা কোথায় প্রবাহিত হবে, এবং প্রোডাকশনে কাজ করার জন্য কী সত্য হতে হবে।
প্রোডাকশন-রেডি মানে শুধু “ডায়াগ্রাম আছে” নয়। এর অর্থ হলো ডিজাইন স্পষ্টভাবে মোকাবিলা করে:
AI প্রারম্ভিক চিন্তাভাবনায় দ্রুততা আনে: প্রার্থী আর্কিটেকচার তৈরিতে, সাধারণ প্যাটার্ন (কিউ, ক্যাশ, সার্ভিস বাউন্ডারি) সুপারিশে, অনুপস্থিত non-functional requirements সামনে আনে, এবং ইন্টারফেস কনট্রাক্ট বা চেকলিস্ট খসড়া করতে ভালো।
AI বিভ্রান্ত করতে পারে যখন এটি এমন স্পেসিফিক সম্পর্কে আত্মবিশ্বাসী শোনায় যা এটি যাচাই করতে পারে না: প্রাসঙ্গিকতা না জেনে প্রযুক্তি বেছে নেওয়া, অপারেশনাল জটিলতা হালকাভাবে দেখা, বা সংস্থার কেবল সে-ই জানে এমন সীমাবদ্ধতা উপেক্ষা করা (কমপ্লায়েন্স, বিদ্যমান প্ল্যাটফর্ম, টিম স্কিল)। আউটপুটগুলোকে চ্যালেঞ্জ করার প্রস্তাব হিসেবে নিন, চূড়ান্ত উত্তর হিসেবে নয়।
এই পোস্ট একটি ব্যবহার্য ও পুনরাবৃত্তিযোগ্য ওয়ার্কফ্লো কভার করে: প্রম্পট → requirements → assumptions → options → decisions, ট্রেডঅফসহ যা ট্রেস করা যায়।
এটি ডোমেইন দক্ষতা, বিস্তারিত সাইজিং, বা নিরাপত্তা রিভিউ বদলাবে না—এবং এটি প্রত্যেক প্রম্পটের জন্য একক “সঠিক” আর্কিটেকচার আছে বলে দাবি করবে না।
একটি অস্পষ্ট প্রম্পট সাধারণত লক্ষ্যমাত্রা (“ড্যাশবোর্ড বানান”), সমাধান ধারনা (“মাইক্রোসার্ভিস ব্যবহার করুন”), এবং মতামত (“দ্রুত করুন”) একসাথে মিশায়। উপাদান আঁকবার আগে, আপনাকে এমন একটি সমস্যা বিবৃতি প্রয়োজন যা পরীক্ষা ও বিতর্ক করার জন্য যথেষ্ট স্পষ্ট।
প্রাথমিক ব্যবহারকারী, তাদের করতে চাওয়া কাজ, এবং জরুরিত্ব নাম করে এক বা দুই বাক্যে লিখুন।
উদাহরণ: “কাস্টমার সাপোর্ট ম্যানেজাররা প্রতিদিন অগ্রাধিকার নির্ধারণ ও এই ত্রৈমাসিকের মধ্যে SLA মিস হ্রাস করার জন্য ওপেন টিকিট ও SLA রিস্কের একটি একক ভিউ প্রয়োজন।”
যদি প্রম্পট কোনো বাস্তব ব্যবহারকারী নির্ধারণ না করে, একটি ব্যবহারকারী চিহ্নিত করতে বলেন। যদি না বলে কেন এখন গুরুত্বপূর্ণ, আপনি পরে ট্রেডঅফ র্যাঙ্ক করতে পারবেন না।
“ভালো”কে পরিমেয় আউটকাম-এ পরিণত করুন। প্রোডাক্ট ও অপারেশনাল সিগন্যালের মিশ্রণ পছন্দ করুন।
ছোট সেট (৩–৫) বেছে নিন। খুব বেশি মেট্রিক বিভ্রান্তি বাড়ায়; খুব কম ঝুঁকি আড়াল করে।
সাধারণ ভাষায় “হ্যাপি পাথ” বর্ণনা করুন, তারপর আর্কিটেকচারকে আকৃতি দেবার জন্য যে এজ কেসগুলো আছে সেগুলো তালিকাভুক্ত করুন।
হ্যাপি পাথ উদাহরণ: ব্যবহারকারী সাইন ইন করে → একটি কাস্টমার সার্চ করে → বর্তমান স্ট্যাটাস দেখে → একটি ফিল্ড আপডেট করে → অডিট লগ রেকর্ড হয়।
আগে থেকেই উত্থাপিত এজ কেস: অফলাইন/নিম্ন সংযোগ, আংশিক অনুমতিসমূহ, ডুপ্লিকেট রেকর্ড, উচ্চ-ভলিউম ইম্পোর্ট, টাইমআউট, রিট্রাই, এবং কোনো ডিপেনডেন্সি ডাউন হলে কী হয়।
এই ভ্যার্সনে আপনি কী নই বানাচ্ছেন তা স্পষ্ট করুন: সমর্থিত নন-কভার করা ইন্টিগ্রেশন, উন্নত অ্যানালিটিক্স, মাল্টি-রিজিয়ন, কাস্টম কার্যপদ্ধতি, বা পূর্ণ অ্যাডমিন টুলিং। স্পষ্ট সীমা সময়সূচী রক্ষা করে এবং পরবর্তীতে “ফেজ ২” আলাপ সহজ করে।
এই চারটি অংশ লেখা হলে, প্রম্পটটি একটি ভাগীদারিত্ব-চুক্তিতে পরিণত হয়। AI সহায়তা করতে পারে এটি পরিমার্জন করতে, কিন্তু এটি নিজে তৈরি করা উচিত নয়।
একটি অস্পষ্ট প্রম্পট প্রায়ই লক্ষ্য (“সহজ করুন”), ফিচার (“নোটিফিকেশন পাঠান”) এবং পছন্দ (“serverless ব্যবহার করুন”) এক বাক্যে মিশায়। এই ধাপে এগুলো আলাদা করে একটি requirements লিস্টে পরিণত করুন যাতে আপনি ডিজাইন করতে পারেন।
কংক্রিট আচরণ ও তা কোন অংশগুলো স্পর্শ করে তা টানুন:
একটি ভালো চেক: প্রতি requirement এর জন্য আপনি কি একটি স্ক্রিন, API এন্ডপয়েন্ট, বা ব্যাকগ্রাউন্ড জব পয়েন্ট করতে পারেন?
এগুলো অধিকাংশ লোকের চেয়ে বেশি আর্কিটেকচারের উপর প্রভাব ফেলে। অস্পষ্ট শব্দগুলোকে পরিমেয় টার্গেটে অনুবাদ করুন:
শুরুতে বাউন্ডারি ধরুন যাতে আপনি এমন একটি সিস্টেম ডিজাইন না করেন যা বাস্তবে শিপ করা যাবে না:
কিছু “done means…” বক্তব্য লিখুন যা যে কেউ যাচাই করতে পারে, উদাহরণ:
এই requirements ও constraints-ই পরবর্তী প্রার্থী আর্কিটেকচারের ইনপুট হবে।
একটি অস্পষ্ট প্রম্পট সাধারণত প্রযুক্তিগত কারণে নয়—বিপর্যয়ের কারণ হয় সবাই চুপচাপ অনুপস্থিত বিবরণগুলো আলাদা ভাবে পূরণ করে। যেকোনো আর্কিটেকচার প্রস্তাব করার আগে AI-কে ব্যবহার করে সেই নীরব অনুমানগুলোকে খোলাখুলি করে তুলুন এবং কী সত্য, কী কল্পনা আলাদা করুন।
প্রারম্ভে সাধারণ যে ডিফল্টগুলো মানুষ ধরে নেয় সেগুলো লিখুন:
এই অনুমানগুলো caching, queues, storage, monitoring, এবং cost-এর মতো পছন্দগুলোকে গভীরভাবে প্রভাবিত করে।
AI-কে অনুরোধ করুন একটি সহজ টেবিল বা তিনটি সংক্ষিপ্ত তালিকা তৈরি করতে:
এটি AI (এবং টিম)-কে অনুমানকে সত্য হিসেবে নেওয়া থেকে রোধ করে।
উপযোগী প্রশ্নের মধ্যে রয়েছে:
স্পষ্টভাবে অনুমানগুলো লিখুন ("Assume peak 2,000 requests/min", "Assume PII present")। এগুলোকে খসড়া ইনপুট হিসেবে পুনর্মূল্যায়ন করুন—আইডিয়ালি প্রত্যেকটির সাথে কে নিশ্চিত করেছে ও কখন নিশ্চিত করেছে তা লিঙ্ক করুন। এটি পরবর্তী ট্রেডঅফ ও আর্কিটেকচার পরিবর্তনগুলো ব্যাখ্যা, রক্ষণ, ও উল্টে ফেলা সহজ করে।
একটি অস্পষ্ট প্রম্পট সাধারণত একমাত্র “সঠিক” ডিজাইন নির্দেশ করে না। প্রোডাকশন-রেডি পরিকল্পনায় পৌঁছানোর দ্রুততম পন্থা হল কয়েকটি কার্যকর অপশন স্কেচ করা, তারপর একটি ডিফল্ট বেছে নেওয়া এবং স্পষ্টভাবে বলা কী পরিস্থিতিতে আপনি পরিবর্তন করবেন।
প্রারম্ভিক প্রোডাক্টগুলির জন্য সাধারণত একটি ডিপ্লয়েবল ব্যাকএন্ড (API + ব্যাবসায়িক লজিক), একটি ডাটাবেস, এবং কয়েকটি ম্যানেজড সার্ভিস (auth, email, object storage) দিয়ে শুরু করা উচিত। এটি ডিপ্লয়, ডিবাগিং, এবং পরিবর্তন সহজ রাখে।
এইটি বেছে নিন যখন: টিম ছোট, requirements পরিবর্তনশীল, এবং ট্রাফিক অনিশ্চিত।
একই ডিপ্লয়েবল, কিন্তু স্পষ্ট ভেতরের মডিউল (billing, users, reporting) এবং স্লো টাস্ক (ইম্পোর্ট, নোটিফিকেশন, AI কল) এর জন্য ব্যাকগ্রাউন্ড ওয়ার্কার যোগ করুন। একটি কিউ ও রিট্রাই নীতি যুক্ত করুন।
এটি বেছে নিন যখন: দীর্ঘ-চলমান টাস্ক আছে, পিরিয়ডিক স্পাইক আছে, বা মালিকানার সীমা পরিষ্কার করতে হবে—কিন্তু আলাদা সার্ভিসে বিভক্ত না করে।
কয়েকটি উপাদান পৃথক সার্ভিসে ভাগ করুন যদি একটি দৃঢ় চালিকা শক্তি থাকে: কঠোর আইসোলেশন (কমপ্লায়েন্স), এক হটস্পটের স্বাধীন স্কেলিং (উদাহরণ: মিডিয়া প্রসেসিং), বা আলাদা রিলিজ সাইকেল।
এটি বেছে নিন যখন: স্পেসিফিক লোড প্যাটার্ন, অর্গ বাউন্ডারি, বা ঝুঁকি সীমাবদ্ধতা আছে যে অতিরিক্ত অপারেশনাল ওভারহেডকে বৈধ করে।
এসব অপশনের মধ্যে স্পষ্টভাবে পার্থক্যগুলি বলুন:
একটি ভাল AI-সহায়ক আউটপুট হলো একটি ছোট ডিসিশন টেবিল: “Default = A, switch to B if background jobs আছে, switch to C if X metric/constraint সত্য।” এটি premature মাইক্রোসার্ভিসিং প্রতিরোধ করে ও আর্কিটেকচারকে বাস্তব requirements-এর সাথে বানানো রাখে।
অদ্ভুতভাবে অনেক আর্কিটেকচার আসলে কেবল সম্মত হওয়ার ব্যাপার—সিস্টেমের ডেটা কী, কোথায় থাকে, এবং কে কী পরিবর্তন করতে পারে সে বিষয়ে। যদি আপনি এটি আগে মডেল করেন, পরে উপাদান, ইন্টারফেস, স্কেলিং, সিকিউরিটি ইত্যাদি অনেক কম অনুমানশীল হয়ে যায়।
সিস্টেম যেখানে ঘুরছে এমন কিছু অবজেক্ট নাম দিয়ে শুরু করুন—সাধারণত প্রম্পট থেকে নাউনগুলো: User, Organization, Subscription, Order, Ticket, Document, Event। প্রতিটি অবজেক্টের জন্য মালিকানা ধরুন:
AI এখানে উপকারী: এটি প্রম্পট থেকে একটি প্রাথমিক ডোমেইন মডেল প্রস্তাব করতে পারে, তারপর আপনি নিশ্চিত করবেন কি বাস্তব এবং কি ইঙ্গিত।
প্রত্যেক অবজেক্ট কি প্রধানত ট্রানজেকশনাল (OLTP) — ছোট পড়া/লিখন অনেক এবং কনসিস্টেন্ট থাকতে হবে — নাকি অ্যানালিটিক্যাল (অ্যাগ্রিগেশন, ট্রেন্ড, রিপোর্টিং)? এই দুইটি চাহিদা এক ডাটাবেসে মিশালে প্রায়ই টানাপোড়েন হয়।
একটি সাধারণ প্যাটার্ন: অ্যাপের জন্য একটি OLTP ডাটাবেস, এবং ইভেন্ট বা এক্সপোর্ট দিয়ে ভর্তা একটি আলাদা অ্যানালিটিক্স স্টোর। কেজিন হল, স্টোরেজটি কীভাবে ব্যবহার হয় তার সাথে সঙ্গত করা, কিভাবে মনে হয় তা নয়।
ডেটা সিস্টেমের মধ্য দিয়ে কীভাবে যায় তা স্কেচ করুন:
ঝুঁকিগুলো স্পষ্টভাবে বলুন: PII হ্যান্ডলিং, ডুপ্লিকেট রেকর্ড, conflicting sources (দুইটি সিস্টেমই সত্য দাবি করা), এবং অস্পষ্ট ডিলিশন সেম্যান্টিকস। এই ঝুঁকি সীমা নির্ধারণ করে: কী রাখতে হবে অভ্যন্তরীণ, কী শেয়ার করা যাবে, এবং কী অডিট ট্রেইল বা অ্যাক্সেস কন্ট্রোল দরকার।
একবার আপনি বাউন্ডারি ও ডেটা পেয়েছেন, সেগুলোকে একটি বাস্তব উপাদান ম্যাপে রূপান্তর করুন: কী আছে, কী মালিকানায় আছে, এবং কীভাবে সবকিছুর সাথে কথা বলে। এখানে AI একটি “শব্দের ডায়াগ্রাম জেনারেটর” হিসেবে সবচেয়ে উপকারী—এটি পরিষ্কার বিভাজন প্রস্তাব করতে পারে এবং মিসিং ইন্টারফেসগুলো খুঁজে পেতে পারে।
কম্পোনেন্ট সংখ্যা ছোট রাখুন এবং পরিষ্কার মালিকানা রাখুন। একটি ভাল চেক: “এটি ভেঙে গেলে কে ঠিক করবে, এবং কী পরিবর্তন হবে?” উদাহরণ:
একটি ডিফল্ট কমিউনিকেশন স্টাইল বেছে নিন এবং ব্যতিক্রমের যুক্তি দিন:
AI প্রতিটি ইউজ কেসকে latency ও নির্ভরযোগ্যতার প্রয়োজন মেটাতে সবচেয়ে সরল ইন্টারফেসে ম্যাপ করে দিতে সাহায্য করতে পারে।
তৃতীয়-পক্ষ সার্ভিসগুলোর তালিকা করুন এবং তাদের ব্যর্থ হলে কী হয় তা সিদ্ধান্ত নিন:
একটি সংক্ষিপ্ত “ইন্টিগ্রেশন টেবিল” লিখুন:
এই ম্যাপ ইমপ্লিমেন্টেশন টিকিট এবং রিভিউ আলোচনার জন্য মেরুদণ্ড হয়ে যাবে।
সাদা বোর্ডে সুন্দর দেখানো ডিজাইনও দিন একে-দিন ব্যর্থ হতে পারে। কোড লেখার আগে “প্রোডাকশন কনট্রাক্ট” স্পষ্ট করুন: লোডের সময়, ব্যর্থতার সময়, আক্রমণের সময় কী হবে—এবং কিভাবে আপনি জানবেন।
সিস্টেম কীভাবে আচরণ করবে যখন ডিপেন্ডেন্সি ধীর বা ডাউন তা নির্ধারণ করে শুরু করুন। টайমআউট, রিট্রাই উইথ জিটার, এবং পরিষ্কার circuit-breaker নিয়ম যোগ করুন। অপারেশনগুলোকে idempotent বানান (রিকোয়েস্ট আইডি বা idempotency কীগুলি ব্যবহার করে) যাতে রিট্রাই নিরাপদ হয়।
তৃতীয়-পক্ষ API কল করলে rate limits ধরে নিন এবং backpressure তৈরি করুন: কিউ, বাউন্ডেড concurrency, এবং গ্রেসফুল ডিগ্রেড (উদাহরণ: “পরে চেষ্টা করুন” উত্তর)।
Authentication (ব্যবহারকারী কীভাবে পরিচয় প্রমাণ করবে) এবং authorization (তারা কী অ্যাক্সেস পাবে) নির্ধারণ করুন। সিস্টেমের সঙ্গে সম্পর্কিত শীর্ষ হুমকি পরিস্থিতি লিখুন: চুরি হওয়া টোকেন, পাবলিক এন্ডপয়েন্টের অপব্যবহার, ইনপুটের মাধ্যমে ইনজেকশন, বা প্রিভিলেজ এসকেলেশন।
সিক্রেটস কোথায় থাকবে, কে পড়তে পারবে, রোটেশন কেমন হবে, এবং অডিট ট্রেইল কেমন হবে তা নির্ধারণ করুন।
ক্ষমতা ও latency টার্গেট (কাঁচা হিসেবে) সেট করুন। তারপর কৌশল বেছে নিন: ক্যাশিং (কি, কোথায়, TTL), চ্যাটি কলের জন্য ব্যাচিং, দীর্ঘ টাস্কের জন্য অ্যাসিঙ্ক কাজ কিউ ব্যবহার, এবং শেয়ার্ড রিসোর্স রক্ষা করতে লিমিট।
স্ট্রাকচার্ড লগ, কীর্ ১ মেট্রিক (latency, error rate, queue depth), ডিস্ট্রিবিউটেড ট্রেসিং সীমা, এবং বেসিক অ্যালার্ট ঠিক করুন। প্রতিটি অ্যালার্টকে একটি কর্মে বাঁধুন: কে রেসপন্ড করবে, কী চেক করবে, এবং “সেইফ মোড” কী দেখায়।
এই পছন্দগুলোকে প্রথম-শ্রেণীর আর্কিটেকচার উপাদান হিসেবেই বিবেচনা করুন—এগুলো এন্ডপয়েন্ট ও ডাটাবেসগুলো যতটা গুরুত্ব রাখে ঠিক ততটাই সিস্টেমকে আকৃতি দেয়।
আর্কিটেকচার একক “সেরা” উত্তর নয়—এটা সীমাবদ্ধতার মধ্যে করা পছন্দগুলোর সেট। AI এখানে দ্রুত অপশন তালিকাভুক্ত করতে সাহায্য করে, কিন্তু আপনাকে এখনও স্পষ্ট রেকর্ড রাখতে হবে কেন আপনি একটি পথ বেছে নিলেন, কি ত্যাগ করলেন, এবং কী আপনাকে পরে পরিবর্তন করাবে।
| Option | Cost | Speed to ship | Simplicity | Scale headroom | Notes / When to revisit |
|---|---|---|---|---|---|
| Managed services (DB, queues, auth) | Medium–High | High | High | High | Revisit if vendor limits/features block needs |
| Self-hosted core components | Low–Medium | Low–Medium | Low | Medium–High | Revisit if ops burden exceeds team capacity |
| Monolith first | Low | High | High | Medium | Split when deploy frequency or team size demands |
| Microservices early | Medium–High | Low | Low | High | Only if independent scaling/ownership is required now |
লিখে রাখুন “গ্রহণযোগ্য ব্যর্থতা” (উদাহরণ: মাঝে মাঝে ডিলেইড ইমেইল) বনাম “অবসোলুট-নন-ফেইল” এলাকা (উদাহরণ: পেমেন্ট, ডেটা লস)। ব্যর্থতা ব্যয়বহুল যেখানে সেখানে সুরক্ষাসম্ভব স্থাপন করুন: ব্যাকআপ, idempotency, rate limits, এবং স্পষ্ট রোলব্যাক পথ।
কিছু ডিজাইন অন-কলে লোড ও ডিবাগিং জটিলতা বাড়ায় (বেশি মুভিং পার্টস, বেশি রিট্রাই, বিতরণকৃত লগ)। আপনার সাপোর্ট বাস্তবতার সাথে মেলে এমন পছন্দ পছন্দ করুন: কম সার্ভিস, পরিষ্কার অবজার্ভেবিলিটি, এবং পূর্বানুমেয় ব্যর্থতা মোড।
ফসফলের সিদ্ধান্ত কriteria স্পষ্ট করুন: কমপ্লায়েন্স প্রয়োজন, কাস্টমাইজেশন, latency, স্টাফিং। যদি কস্টের কারণে সেল্ফ-হোস্ট বেছে নেন, লুকানো মূল্য নোট করুন: প্যাচিং, আপগ্রেড, ক্যাপাসিটি প্ল্যানিং, এবং ইনসিডেন্ট রেসপন্স।
দারুন আর্কিটেকচারগুলো কেবল “হয়ে যায়” না—ওগুলো অনেক ছোট পছন্দের ফল। যদি সেই পছন্দগুলো কেবল চ্যাট লোগ বা কারো স্মৃতিতে থাকে, টিম পুনরায় বিতর্ক করবে, অসামঞ্জস্যে শিপ করবে, এবং প্রয়োজন পরিবর্তিলে সংগ্রাম করবে।
প্রতি মূল পছন্দের জন্য একটি Architecture Decision Record (ADR) তৈরি করুন। এটি সংক্ষিপ্ত ও ধারাবাহিক রাখুন:
AI এখানে বিশেষভাবে উপকারী: এটি আলোচনা থেকে অপশন সারাংশ করতে, ট্রেডঅফ বের করতে, এবং ADR খসড়া তৈরি করতে পারে যাতে আপনি পরে সঠিকতা অনুকূলে সম্পাদনা করেন।
অনুমান বদলে যায়: ট্রাফিক দ্রুত বাড়ে, কমপ্লায়েন্স কঠোর হয়, বা বাইরের API অনির্ভরযোগ্য হয়ে যায়। প্রতিটি বড় অনুমানের জন্য একটি exit ramp যোগ করুন:
এটা ভবিষ্যতের পরিবর্তনকে পরিকল্পিত পদক্ষেপে পরিণত করে, আগুন নেভানোর ড্রিল নয়।
ঝুঁকিপূর্ণ পছন্দগুলোর সাথে টেস্টেবল মাইলস্টোন সংযুক্ত করুন: স্পাইক, বেঞ্চমার্ক, ছোট প্রোটোটাইপ, বা লোড টেস্ট। প্রত্যাশিত ফলাফল ও সাকসেস ক্রাইটেরিয়া রেকর্ড করুন।
অবশেষে, requirements বাড়ার সাথে ADR-গুলো ভার্সন করুন। ইতিহাস ওভাররাইট করবেন না—আপডেট হিসেবে যোগ করুন যাতে কী পরিবর্তিত হলো, কখন, এবং কেন তা ট্রেস করা যায়। যদি হালকা কাঠামো লাগে, একটি অভ্যন্তরীণ টেমপ্লেট লিঙ্ক করুন যেমন /blog/adr-template।
একটি খসড়া আর্কিটেকচার তখনই “ডান” হয় না যখন এটা ডায়াগ্রামে সুন্দর দেখায়। এটি তখনই ডান যখন যাঁরা গড়বেন, সুরক্ষিত করবেন, চালাবেন, এবং দেবেন তাঁরা একমত যে এটি কাজ করে—এবং যখন ঝুঁকিপূর্ণ অংশগুলোর জন্য আপনার কাছে প্রমাণ আছে।
একটি সংক্ষিপ্ত চেকলিস্ট ব্যবহার করে গুরুত্বপূর্ণ প্রশ্নগুলো আগে তুলুন:
আউটপুটটি কংক্রিট রাখুন: “আমরা কী করব?” এবং “কে দায়িত্ব নিবে?” সাধারণ সুসংকল্প নয়।
একটি একক থ্রুপুট অনুমানের বদলে লোড এবং কস্ট রেঞ্জ দিন যা অনিশ্চয়তা প্রতিফলিত করে:
AI-কে তার গণিত ও অনুমান দেখাতে বলুন, তারপর বর্তমান অ্যানালিটিক্স বা তুলনীয় সিস্টেমের সঙ্গে স্যানিটি-চেক করুন।
সমালোচনামূলক ডিপেনডেন্সিগুলি তালিকাভুক্ত করুন (LLM প্রোভাইডার, ভেক্টর DB, কিউ, auth সার্ভিস)। প্রতিটির জন্য ধরুন:
রিভিউগুলো স্পষ্টভাবে নির্ধারণ করুন, না যে-মতিভাবে ধারণা করা হয়:
যখন অমীমাংসিত মতানৈক্য থাকে, সেগুলোকে সিদ্ধান্ত-নেয়া প্রয়োজনীয় বিষয় হিসেবে রেকর্ড করুন—তারপর স্পষ্ট মালিক ও তারিখ দিয়ে এগিয়ে যান।
AI যদি আপনি এটিকে জুনিয়র আর্কিটেক্টের মতো ধরেন তা হলে শক্ত ডিজাইন পার্টনার হতে পারে: দ্রুত অপশন জেনারেট করে, কিন্তু স্পষ্ট প্রসঙ্গ, চেক, ও দিকনির্দেশনার প্রয়োজন।
AI-কে একটি “বক্স” দিন: ব্যবসায়িক লক্ষ্য, ব্যবহারকারী, স্কেল, বাজেট, ডেডলাইন, এবং কোনো নন-নেগোশিয়েবল (টেক স্ট্যাক, কমপ্লায়েন্স, হোস্টিং, latency)। তারপর এটাকে বলুন প্রথমে assumptions এবং open questions তালিকা করতে, তারপর সমাধান প্রস্তাব করতে।
একটি সহজ নিয়ম: যদি একটি কনস্ট্রেইন্ট গুরুত্বপূর্ণ, স্পষ্টভাবে বলুন—মডেল থেকে এটি অনুমান করবেন না।
যদি আপনার লক্ষ্য “আর্কিটেকচার পরিকল্পনা” থেকে “চলমান সিস্টেম” পর্যন্ত সিদ্ধান্ত হারাতে না দেওয়া, তখন একটি ওয়ার্কফ্লো টুল গুরুত্বপূর্ণ। প্ল্যাটফর্মগুলো—যেমন Koder.ai—সহায়ক হতে পারে কারণ একই চ্যাট যা requirements স্পষ্ট করতে সাহায্য করে তা ইমপ্লিমেন্টেশনে constraints বহন করতে পারে: পরিকল্পনা মোড, পুনরাবৃত্তিযোগ্য ইটারেশন, এবং যখন আপনি পাইললাইন নিজে চালাতে চান তখন সোর্স কোড এক্সপোর্ট করার সুবিধা।
এটি আর্কিটেকচার রিভিউগুলির প্রয়োজন মুছে দেয় না—বরং অনুমান ও non-functional requirements ডকুমেন্ট করার মান বাড়ায়—কারণ আপনি প্রস্তাব থেকে রানিং অ্যাপে দ্রুত যেতে পারবেন।
সংক্ষিপ্ত টেমপ্লেট ব্যবহার করুন যা স্ট্রাকচার্ড আউটপুট দেয়:
You are helping design a system.
Context: <1–3 paragraphs>
Constraints: <bullets>
Non-functional requirements: <latency, availability, security, cost>
Deliverables:
1) Assumptions + open questions
2) 2–3 candidate architectures with pros/cons
3) Key tradeoffs (what we gain/lose)
4) Draft ADRs (decision, alternatives, rationale, risks)
(উপরের কোড-ব্লকটি অনুবাদ করা হয়নি।)
প্রথম পাস চাইুন, তারপর সঙ্গে সঙ্গে একটি সমালোচনা অনুরোধ করুন:
এতে মডেল এক পথে আটকে পড়া থেকে বিরত থাকে।
AI আত্মবিশ্বাসী শোনাতে পারে কিন্তু ভুল হতে পারে। সাধারণ সমস্যাগুলো:
আপনি চাইলে আউটপুটগুলোকে লাইটওয়েট ADR হিসেবে ক্যাপচার করে রেপোর পাশে রাখতে পারেন (দেখুন /blog/architecture-decision-records)।
একটি অস্পষ্ট প্রম্পট: “গ্রাহককে জানানো সিস্টেম বানান যখন ডেলিভারি লেট হবে।”
AI এইটিকে কংক্রিট প্রয়োজনীয়তায় অনুবাদ করতে সাহায্য করে:
দুইটি প্রাথমিক প্রশ্ন প্রায়ই ডিজাইন উল্টে দেয়:
এসগুলো লিখে রাখা আপনাকে দ্রুত ভুল জিনিস বানানো থেকে রক্ষা করবে।
AI প্রার্থী আর্কিটেকচার প্রস্তাব করে:
Option 1: Synchronous API: carrier webhook → delay scoring service → notification service
Option 2: Queue-based: webhook → enqueue event → workers score delays → notifications
ট্রেডঅফ সিদ্ধান্ত: যদি ক্যারিয়ার নির্ভরযোগ্য না এবং ট্রাফিক স্পাইক রিস্ক থাকে, queue-based বেছে নিন; যদি ভলিউম কম এবং ক্যারিয়ার SLA শক্তিশালী হয়, synchronous বেছে নিন।
নির্মাণযোগ্য করার জন্য ডেলিভারেবলগুলো:
"প্রম্পট থেকে আর্কিটেকচার" হলো একটি ওয়ার্কফ্লো যা একটি উদ্দেশ্য (যেমন "কাস্টমার পোর্টাল বানান") কে একটি নির্মাণযোগ্য পরিকল্পনায় রূপান্তর করে: requirements, assumptions, candidate options, explicit decisions, এবং উপাদান ও ডেটা ফ্লো-এর একটি শেষ-টু-শেষ ভিউ।
AI-এর আউটপুটকে প্রস্তাব হিসেবে গ্রহণ করুন যা আপনি পরীক্ষা ও সম্পাদনা করবেন—চূড়ান্ত উত্তর হিসেবে নয়।
প্রোডাকশন-রেডি মানে ডিজাইনটি স্পষ্টভাবে কভার করে:
ডায়াগ্রাম সহায়ক, কিন্তু তা পর্যাপ্ত শর্ত নয়।
1–2 বাক্যে স্পষ্ট করুন:
যদি প্রম্পট বাস্তব ব্যবহারকারী বা জরুরি কারণ উল্লেখ না করে, তাদের সম্পর্কে জিজ্ঞাসা করুন—নাহলে পরে tradeoffs র্যাঙ্ক করা যাবে না।
3–5 পরিমেয় মেট্রিক্স নির্বাচন করুন যা প্রোডাক্ট ও অপারেশনাল উভয় দিককে মাপে, উদাহরণ:
“মেট্রিক স্প্রোল” এড়ান: অনেক হলে অগ্রাধিকার অস্পষ্ট হবে; খুব কম হলে ঝুঁকি অদৃশ্য থাকে।
প্রতিটি প্রকল্পে সাধারণভাবে ধরা নীচের ডিফল্টগুলো লিখে নিন (ট্রাফিক, ডেটা কোয়ালিটি, ব্যবহারকারীর ধৈর্য্য, অন-কলে কভারেজ ইত্যাদি), তারপর বিভাগ করুন:
অ্যাসাম্পশন গুলো স্পষ্টভাবে ডকুমেন্ট করুন (কে/কখন নিশ্চিত করেছে) যাতে পরে চ্যালেঞ্জ করা যায়।
প্রাথমিকভাবে একাধিক বৈধ অপশন দিয়ে শুরু করুন এবং একটি ডিফল্ট নির্ধারণ করুন যার জন্য স্পষ্ট “switch conditions” থাকবে, উদাহরণ:
লক্ষ্য হল ট্রেসেবল ট্রেডঅফ, এমন নয় যে একটাই “সঠিক” ডিজাইন।
কোর ডোমেইন অবজেক্টগুলো নাম দিন (নাউনগুলো: User, Order, Ticket, Event) এবং প্রতিটির জন্য নির্ধারণ করুন:
প্রতিটি ডিপেনডেন্সির জন্য (পেমেন্ট, মেসেজিং, LLM, ইন্টারনাল APIs) ব্যর্থতার আচরণ নির্ধারণ করুন:
ধারণা করুন যে rate limits আছে এবং backpressure ডিজাইন করুন যাতে স্পাইকগুলো cascade করে আউটেজ না পড়ে।
প্রতিটি মূল পছন্দের জন্য একটি ADRs তৈরি করুন যা অন্তর্ভুক্ত করবে:
প্রতি বড় অনুমান/ডিসিশনের জন্য একটি “exit ramp” যুক্ত করুন (ট্রিগার নির্দিষ্ট করে যেমন: “যদি X RPS ছাড়িয়ে যায়, read replicas যোগ করা”). ADR গুলো সার্চযোগ্য ও ভার্সন্ড হওয়া উচিত; একটি হালকা ওজনের টেমপ্লেট /blog/adr-template-এ রাখুন।
AI-কে একটি সংকীর্ণ বক্স দিন: লক্ষ্য, ব্যবহারকারী, স্কেল, কনস্ট্রেইন্ট (বাজেট, ডেডলাইন, কমপ্লায়েন্স, স্ট্যাক) এবং বলুন:
তারপর “critique and refine” লুপ চালান (কী ভঙ্গুর, কী মিসিং, কী সরল করা যায়)। নিশ্চিত হোন মডেলের আত্মবিশ্বাসপূর্ণ কিন্তু যাচাই করা না যায় এমন অংশগুলোর জন্য স্পষ্ট অনিশ্চয়তা আছে।
তারপর স্টোরেজ প্যাটার্ন নির্বাচন করুন যে অনুযায়ী access pattern (OLTP বনাম analytics) মিলবে, এবং ইন্ড-টু-এন্ড ডেটা ফ্লো স্কেচ করুন (ingestion → validation/enrichment → retention/deletion)।