আর্কিটেকচারের সিদ্ধান্তে AI: বিকল্প, ADR আর ডায়াগ্রাম

আর্কিটেকচারের প্রশ্নে “সঠিক উত্তর” খুব কম থাকে; থাকে ভালো-মন্দের হিসাব (trade-off)। এখানে AI-এর সবচেয়ে বড় কাজ হলো দ্রুত বিকল্প সাজিয়ে দেওয়া আর সিদ্ধান্তটা লেখার খসড়া বানানো। Simon Willison-ও বলছেন, প্রজেক্টের শুরুতে “কী কী উপায় আছে” জানতে তিনি LLM ব্যবহার করেন। কিন্তু সিদ্ধান্ত নেবেন আপনি, কারণ আপনার দল, বাজেট আর ঝুঁকি AI জানে না, যদি না আপনি বলেন।

ধাপ ১: প্রেক্ষাপট সংখ্যা দিয়ে দিন

“Microservices ভালো নাকি monolith?” এভাবে জিজ্ঞেস করলে উত্তর হবে বইয়ের মতো সাধারণ। বরং আপনার আসল অবস্থা দিন: দলের আকার, প্রযুক্তি, লোড আর আসল সমস্যা। তারপর বলুন ঠিক কী কী চান।

আমরা দুইজন ডেভেলপার একটা অনলাইন দোকান চালাই (একটা সার্ভারে Django + PostgreSQL)। ঈদের আগে দিনে ৫,০০০ পর্যন্ত অর্ডার আসে, বছরের বাকি সময় ৫০০-এর মতো। bKash পেমেন্টের callback মাঝে মাঝে দেরিতে আসে। আমরা ভাবছি microservices-এ যাব কি না।
১. ৩টি বিকল্প দিন, আমাদের দলের আকারের হিসাবে প্রতিটির সুবিধা ও অসুবিধা।
২. একটা সুপারিশ করুন।
৩. Michael Nygard-এর ফরম্যাটে একটা ADR লিখুন (Title, Status, Context, Decision, Consequences)।
৪. শেষে সুপারিশ করা ডিজাইনের Mermaid flowchart কোড দিন।

১

বড় করে দেখতে ছবিতে চাপ দিন

1. ১দল, লোড আর সমস্যার সংখ্যাসহ প্রেক্ষাপট, তারপর চারটা চাওয়া

ধাপ ২: বিকল্প আর সুপারিশ পড়ুন

১

বড় করে দেখতে ছবিতে চাপ দিন

1. ১মূল পরামর্শ, তারপর তিনটা বিকল্প

ChatGPT তিনটা বিকল্প দিয়েছে: সাধারণ monolith, modular monolith আর background worker, আর microservices। সুপারিশ দ্বিতীয়টা: এখনই microservices নয়। যুক্তিটা আমাদের প্রেক্ষাপট থেকেই এসেছে: দুইজনের দলের জন্য আলাদা আলাদা service চালানো, পর্যবেক্ষণ আর debug করার বোঝা অনেক বেশি, আর আসল সমস্যা (দেরিতে আসা callback) service ভাগ করলে নিজে থেকে মিটবে না।

এই ধরনের উত্তর পড়ার সময় তিনটা জিনিস মিলিয়ে নিন:

• আপনার সংখ্যা ঠিক এসেছে কিনা। এখানে ৫০০ আর ৫,০০০ দুটোই ঠিক এসেছে।
• প্রতিটা অসুবিধা আপনার অবস্থার সাথে মেলে কিনা, নাকি সাধারণ বইয়ের কথা।
• কোন প্রশ্নের উত্তর নেই। যেমন আমাদের সার্ভার এখন কতটা চাপ নিতে পারে, তা AI জানে না। সেটা মাপতে হবে load test দিয়ে।

ধাপ ৩: ADR-টা ঠিক করুন

ADR (Architecture Decision Record) হলো একটা ছোট নথি, যেখানে লেখা থাকে কেন একটা সিদ্ধান্ত নেওয়া হয়েছিল। Michael Nygard ২০১১ সালে এর পাঁচ অংশ ঠিক করেছিলেন: Title, Context, Decision, Status, Consequences। তাঁর যুক্তি: কারণ লেখা না থাকলে নতুন কেউ পুরোনো সিদ্ধান্ত হয় অন্ধভাবে মেনে নেয়, নয় অন্ধভাবে বদলে ফেলে।

ChatGPT-এর ADR-এ পাঁচটা অংশই আছে, আর Consequences-এ ভালো দিকের পাশাপাশি খারাপ দিকও আছে (queue আর worker চালানোর বাড়তি কাজ)। Nygard-ও ঠিক এটাই বলেছিলেন: শুধু ভালো ফল নয়, সব ফল লিখতে হবে।

কিন্তু একটা জিনিস ঠিক করতে হবে। Status-এ ChatGPT লিখেছে “Accepted”। Nygard-এর নিয়মে দলের সবাই রাজি হওয়ার আগে status হবে Proposed। আমরা এই পরীক্ষা তিনবার চালিয়েছি, তিনবারই “Accepted” লিখেছে। সিদ্ধান্ত হয়েছে কিনা, সেটা AI ঠিক করতে পারে না; আপনার দল করবে।

ধাপ ৪: Mermaid কোড দিয়ে ডায়াগ্রাম দেখুন

১

বড় করে দেখতে ছবিতে চাপ দিন

1. ১Mermaid কোড: উপরের কপি বোতাম দিয়ে কপি করুন

কোডটা কপি করে mermaid.live-এ খুলুন। বাঁ দিকের Code বক্সের লেখা মুছে কোডটা পেস্ট করুন, ডান দিকে ডায়াগ্রাম সাথে সাথে চলে আসবে।

১২

বড় করে দেখতে ছবিতে চাপ দিন

1. ১এখানে কোড পেস্ট করুন
2. ২ডায়াগ্রাম এখানে আসে

ডায়াগ্রাম দেখে নিজেকে জিজ্ঞেস করুন: callback দুইবার এলে কী হয়? callback একেবারেই না এলে কী হয়? দুটো পথই কি ডায়াগ্রামে আছে? না থাকলে ChatGPT-কে বলুন সেই পথ যোগ করতে। ডায়াগ্রামে ফাঁক দেখা লেখার চেয়ে সহজ, এটাই ডায়াগ্রামের আসল লাভ।

মূল উৎস

• Michael Nygard, Documenting Architecture Decisions (Cognitect, নভেম্বর ২০১১): ADR-এর পাঁচ অংশ, Status-এর নিয়ম, আর সব ফল লেখা।
• Mermaid, Flowchart syntax: flowchart কোডের নিয়ম।
• Simon Willison, Here’s how I use LLMs to help me write code (মার্চ ২০২৫): শুরুতে বিকল্প জানতে LLM ব্যবহার।