প্রোটোটাইপকে নির্ভরযোগ্য SaaS-এ রূপান্তরের সময় দলগুলো যে বাস্তবপক সিদ্ধান্তগুলো করে: ডেটা ফ্লো, কনসিস্টেন্সি, এবং লোড কন্ট্রোল সহজ ভাষায় ব্যাখ্যা।

InvoiceCreated ইভেন্ট স্ট্রিম প্রত্যেক ফিচারকে সাবস্ক্রাইব করতে দেয় কোনো মূল সার্ভিসকে জটিল করার দরকার ছাড়া।\n\n## ইভেন্ট ডিজাইন: আপনি কী প্রকাশ করবেন এবং কী রাখবেন\n\nপণ্যে বৃদ্ধির সাথে ইভেন্টগুলো “ভালো থাকার মতো” হওয়া বন্ধ করে এবং একটি সেফটি নেটে পরিণত হয়। ভাল ইভেন্ট ডিজাইন আসলে দুই প্রশ্নে স্বংক্ষেপিত: আপনি কী ফ্যাক্ট রেকর্ড করবেন, এবং অন্য অংশগুলো কিভাবে অনুমানের দরকার ছাড়াই প্রতিক্রিয়া জানাতে পারবে?\n\nবিজনেস ইভেন্টের একটি ছোট সেট থেকে শুরু করুন। ব্যবহারকারী ও অর্থের পক্ষে গুরুত্বপূর্ণ মুহূর্তগুলো বেছে নিন: UserSignedUp, EmailVerified, SubscriptionStarted, PaymentSucceeded, PasswordResetRequested.\n\nনামগুলা কোডের জীবনকাল ছাড়িয়ে যায়। সম্পন্ন ফ্যাক্টের জন্য অতীত কাল ব্যবহার করুন, তাদের নির্দিষ্ট রাখুন, এবং UI শব্দ ব্যবহার করা থেকে বিরত থাকুন। PaymentSucceeded তখনও অর্থবোধক থাকবে যদি পরে আপনি কুপন, রিট্রাই, বা একাধিক পেমেন্ট প্রোভাইডার যোগ করেন।\n\nইভেন্টগুলোকে কনট্রাক্ট হিসেবে বিবেচনা করুন। একটি “UserUpdated” ধরার-অল এড়িয়ে চলুন যেখানে প্রতিটি স্প্রিন্টে বিভিন্ন ফিল্ড যোগ-বিয়োগ হয়। যতটা সম্ভব ছোট ফ্যাক্ট রাখুন যা আপনি বছরের পর বছর ধরে সমর্থন করতে পারবেন।\n\nনিরাপদভাবে বিবর্তিত করতে, অ্যাডিটিভ পরিবর্তনকে অগ্রাধিকার দিন (নতুন অপশনাল ফিল্ড)। যদি ব্রেকিং পরিবর্তন দরকার হয়, নতুন ইভেন্ট নাম (বা স্পষ্ট ভার্সন) প্রকাশ করুন এবং পুরনো কনজিউমাররা চলে যাওয়া পর্যন্ত দুটো চালিয়ে নিন।\n\nআপনি কী সংরক্ষণ করবেন? যদি আপনি কেবল ডাটাবেসে সর্বশেষ সারি রাখেন, আপনি সেখানে পৌঁছানোর গল্প হারান।\n\nর’অ ক events অডিট, রিপ্লে, ও ডিবাগিংয়ের জন্য দারুণ। স্ন্যাপশট দ্রুত রিড এবং দ্রুত রিকভারের জন্য সুবিধাজনক। অনেক SaaS উভয়ই ব্যবহার করে: কেমান কিওয়ার্কফ্লো (বিলিং, পারমিশন) জন্য র’অ ইভেন্ট সংরক্ষণ করুন এবং ইউজার-ফেসিং স্ক্রিনের জন্য স্ন্যাপশট বজায় রাখুন।\n\n## ব্যবহারকারীরা বাস্তবে অনুভব করা কনসিস্টেন্সি ট্রেডঅফ\n\nকনসিস্টেন্সি এমন মুহূর্তগুলোতে দেখা যায়: “আমি আমার প্ল্যান বদলেছি, কেন এখনও Free দেখাচ্ছে?” বা “আমি একটা ইনভাইট পাঠিয়েছি, কেন আমার টিমমেট এখনও লগইন করতে পারছে না?”\n\nস্ট্রং কনসিস্টেন্সি মানে আপনি সফল মেসেজ পেলেই প্রতিটি স্ক্রিন তৎক্ষণাত নতুন স্টেট প্রতিফলিত করবে। ইভেন্টুয়াল কনসিস্টেন্সি মানে পরিবর্তন সময়ের সঙ্গে ছড়িয়ে পড়ে, এবং একটি সংক্ষিপ্ত উইন্ডোতে অ্যাপের বিভিন্ন অংশ আলাদা ধারণা রাখতে পারে। কোনটিই “ভাল” নয়—আপনি সিদ্ধান্ত নেন কোন মিলবৈপরীত্য কতটা ক্ষতি করতে পারে।\n\nস্ট্রং কনসিস্টেন্সি সাধারণত টাকা, অ্যাক্সেস, এবং নিরাপত্তার জন্য উপযুক্ত: কার্ড চার্জ, পাসওয়ার্ড পরিবর্তন, API কী প্রত্যাহার, সিট লিমিট-এর প্রয়োগ। ইভেন্টুয়াল কনসিস্টেন্সি সাধারণত কার্যকলাপ ফিড, সার্চ, অ্যানালিটিক্স ড্যাশবোর্ড, “last seen,” এবং নোটিফিকেশনের জন্য যুক্তিযুক্ত।\n\nযদি আপনি স্টেলনেস গ্রহণ করেন, তাতে লুকোন না, বরং তার জন্য ডিজাইন করুন। UI-কে সৎ রাখুন: একটি_WRITE হওয়ার পর Until কনফার্মেশন না আসা পর্যন্ত “Updating…” দেখান, তালিকার জন্য ম্যানুয়াল রিফ্রেশ অফার করুন, এবং অপ্টিমিস্টিক UI কেবল তখন ব্যবহার করুন যখন আপনি সহজে রোলব্যাক করতে পারেন।\n\nরিট্রাই-এ কনসিস্টেন্সি চতুর হয়ে যায়। নেটওয়ার্ক ড্রপ করে, ক্লায়েন্ট ডাবল-ক্লিক করে, ওয়ার্কার রিস্টার্ট করে। গুরুত্বপূর্ণ অপারেশনের জন্য রিকোয়েস্টগুলো idempotent করুন যাতে একই অ্যাকশন পুনরায় করতে গেলে দুইটি ইনভয়েস, দুইটি ইনভাইট, বা দুইটি রিফান্ড না ঘটে। একটি সাধারণ পদ্ধতি হল প্রতি অ্যাকশনের জন্য একটি idempotency key এবং সার্ভার-সাইড নিয়ম যাতে পুনরাবৃত্তির ক্ষেত্রে মূল ফলাফল ফেরত দেয়া হয়।\n\n## ব্যাকপ্রেশার: সিস্টেমকে পুড়ে যেতে না দেওয়ার উপায়\n\nব্যাকপ্রেশার দরকার যখন রিকোয়েস্ট বা ইভেন্ট আপনার সিস্টেম সামলাতে সক্ষমতার থেকে দ্রুত আসছে। এ ছাড়া কাজ মেমরিতে জমা হয়, কিউ বড় হয়, এবং সবচেয়ে ধীর ডিপেনডেন্সি (প্রায়ই ডাটাবেস) ঠিক করে দেয় কবে সবকিছু ব্যর্থ হবে।\n\nসরল ভাষায়: আপনার প্রডিউসার কথা বলা চালিয়ে যায় আর আপনার কনজিউমার ডুবছে। আপনি যদি আরো কাজ গ্রহণ করতে থাকেন, আপনি কেবল ধীর হচ্ছেন না; আপনি টাইমআউট ও রিট্রাইয়ের একটি চেইন রূপে লোডকে গুণ করছেন।\n\nসতর্ক সংকেতগুলো সাধারণত আউটেজের আগে দৃশ্যমান: ব্যাকলগ কেবল বাড়ে, স্পাইক বা ডিপ্লয় পরে ল্যাটেন্সি ঝাঁপ দেয়, রিট্রাই টাইমআউটের সঙ্গে বাড়ে, অনভিষ্ঠ এন্ডপয়েন্টগুলো ব্যর্থ হয় যখন একটি ডিপেনডেন্সি ধীর হয়ে যায়, এবং ডাটাবেস কানেকশন সীমায় বসে থাকে।\n\nআপনি যখন সেই বিন্দুতে পৌঁছান, পূর্ণ হলে কী হবে তার জন্য একটি পরিষ্কার নিয়ম নিন। লক্ষ্য সবকিছু কোনো মূল্যে প্রসেস করা নয়। লক্ষ্য হলো বেঁচে থাকা এবং দ্রুত পুনরুদ্ধার করা। টিমগুলো সাধারণত এক বা দুটি নিয়ন্ত্রণ নিয়ে শুরু করে: রেট লিমিট (প্রতি ব্যবহারকারী বা API কী), নির্দিষ্ট বাউন্ডেড কিউ যার একটি ড্রপ/ডিলে পলিসি আছে, ব্যর্থ ডিপেনডেন্সির জন্য সার্কিট ব্রেকার, এবং ইন্টারঅ্যাকটিভ রিকোয়েস্টকে প্রায়োরিটি যাতে ব্যাকগ্রাউন্ড জবের উপর জয় পাওয়া যায়।\n\nপ্রথমে ডাটাবেসকে রক্ষা করুন। কানেকশন পুল ছোট ও পূর্বানুমেয় রাখুন, কুয়েরি টাইমআউট সেট করুন, এবং ad-hoc রিপোর্টের মতো ব্যয়বহুল এন্ডপয়েন্টগুলোর উপর কঠোর সীমা রাখুন।\n\n## বড়ো করে না লিখে রিলায়বিলিটি অর্জনের ধাপগুলো\n\nরিলায়বিলিটি সাধারণত বড়ো রিরাইটের প্রয়োজন হয় না। এটি সাধারণত কয়েকটি সিদ্ধান্ত থেকে আসে যা ব্যর্থতাকে দৃশ্যমান, সীমাবদ্ধ, এবং পুনরুদ্ধারযোগ্য করে তোলে।\n\nবিশ্বাস অর্জন বা হারানোর ফ্লোগুলো থেকে শুরু করুন, তারপর ফিচার যোগ করার আগে সেফটি রেল যোগ করুন:\n\n1. ক্রিটিক্যাল পাথ ম্যাপ করুন। সাইনআপ, লগইন, পাসওয়ার্ড রিসেট, এবং কোনো পেমেন্ট ফ্লো-এর সঠিক ধাপগুলো লিখে রাখুন। প্রতিটি ধাপের জন্য তার ডিপেনডেন্সি (ডাটাবেস, ইমেইল প্রোভাইডার, ব্যাকগ্রাউন্ড ওয়ার্কার) তালিকাভুক্ত করুন। এটি কি অবিলম্বে হতে হবে বনাম কি “eventually” ঠিক করা যাবে তা স্পষ্ট করে।\n\n2. অবজারভেবিলিটি বেসিক যোগ করুন। প্রতিটি রিকোয়েস্টকে একটি ID দিন যা লগে দেখা যায়। এমন একটি ছোট সেট মেট্রিক্স ট্র্যাক করুন যা ব্যবহারকারীর কষ্টের সাথে মিলে: এরর রেট, ল্যাটেন্সি, কিউ ডেপথ, এবং ধীর কুয়েরি। যে জায়গায় রিকোয়েস্ট সার্ভিস পেরোয় সেখানে ট্রেস যোগ করুন।\n\n3. ধীর বা ফ্লেকি কাজ আলাদা করুন। বাইরে কোনো সার্ভিসকে কল করা বা নিয়মিত 1 সেকেন্ডের বেশি সময় নেওয়া যেকোনো কাজ জব ও ওয়ার্কার-এ স্থানান্তর করুন।\n\n4. রিট্রাই ও পার্শিয়াল ব্যর্থতার জন্য ডিজাইন করুন। টাইমআউট হবে এটাই ধরে নিন। অপারেশনগুলো idempotent করুন, ব্যাকঅফ ব্যবহার করুন, সময়সীমা সেট করুন, এবং ইউজার-ফেসিং একশানগুলো সংক্ষিপ্ত রাখুন।\n\n5. রিকভারি অনুশীলন করুন। ব্যাকআপগুলো কেবল তখনই মূল্যবান যদি আপনি সেগুলো রিস্টোর করতে পারেন। ছোট রিলিজ ব্যবহার করুন এবং দ্রুত রোলব্যাক পথ রাখুন।\n\nযদি আপনার টুলিং স্ন্যাপশট ও রোলব্যাক সমর্থন করে (Koder.ai করে), সেগুলোকে অভ্যাসে ঢুকান, জরুরি ট্রিক হিসেবে নয়।\n\n## উদাহরণ: একটি ছোট SaaS-কে নির্ভরযোগ্য করে তোলা\n\nএকটি ছোট SaaS ধরুন যা টিমগুলোকে নতুন ক্লায়েন্ট অনবোর্ড করতে সাহায্য করে। ফ্লো সহজ: একজন ব্যবহারকারী সাইন আপ করে, প্ল্যান পছন্দ করে, পেমেন্ট করে, এবং একটি স্বাগত ইমেইল ও কিছু “শুরু করার ধাপ” পায়।\n\nপ্রোটোটাইপে সবকিছু এক রিকোয়েস্টে হয়: অ্যাকাউন্ট তৈরি, কার্ড চার্জ, ব্যবহারকারীর “paid” ফ্ল্যাগ অন, ইমেইল পাঠানো। এটি চলবে যতক্ষণ না ট্রাফিক বাড়ে, রিট্রাই ঘটে, এবং বাইরের সার্ভিস ধীর হয়ে যায়।\n\nনির্ভরযোগ্য করতে টিমটা মূল অ্যাকশনগুলোকে ইভেন্টে পরিণত করে এবং একটি অ্যাপেন্ড-অনলি ইতিহাস রাখে। তারা কয়েকটি ইভেন্ট পরিচয় করায়: UserSignedUp, PaymentSucceeded, EntitlementGranted, WelcomeEmailRequested। এতে অডিট ট্রেইল মিলে, অ্যানালিটিক্স সহজ হয়, এবং ধীর কাজ ব্যাকগ্রাউন্ডে হতে পারে সাইনআপ ব্লক না করে।\n\nকয়েকটি সিদ্ধান্তই বড়ো কাজ করে:\n\n- অ্যাক্সেসের সোর্স অফ ট্রুথ হিসেবে পেমেন্টকে বিবেচনা করুন, কেবল একটি “paid” ফ্ল্যাগ নয়।\n- PaymentSucceeded থেকে entitlement প্রদান করুন একটি স্পষ্ট idempotency key দিয়ে যাতে রিট্রাই ডাবল-গ্রান্ট না করে।\n- চেকআউট রিকোয়েস্ট থেকে ইমেইল পাঠাবেন না; ইমেইল পাঠান কিউ/ওয়ার্কার থেকে।\n- ইভেন্ট রেকর্ড করুন এমনকি যদি হ্যান্ডলার ব্যর্থ হয়, যাতে আপনি রিপ্লে ও রিকভার করতে পারেন।\n- বাইরের প্রোভাইডারের চারপাশে টাইমআউট ও সার্কিট ব্রেকার যোগ করুন।\n\nযদি পেমেন্ট সফল হয় কিন্তু অ্যাক্সেস এখনও না দেওয়া হয়, ব্যবহারকারীরা প্রতারণার বোধ করবে। ঠিক করা যাবে না “সবার জায়গায় নিখুঁত কনসিস্টেন্সি” দিয়ে। বরং কি অবিলম্বে কনসিস্টেন্ট থাকতে হবে তা সিদ্ধান্ত নিন, এবং UI-তে সেই সিদ্ধান্ত প্রতিফলিত করুন, যেমন EntitlementGranted না আসা পর্যন্ত “Activating your plan” অবস্থা দেখানো।\n\nখারাপ দিনে ব্যাকপ্রেশারই পার্থক্য তৈরি করে। যদি ইমেইল API একটি মার্কেটিং ক্যাম্পেইনের সময় ধীর হয়ে যায়, পুরনো ডিজাইন চেকআউট টাইমআউট করে এবং ব্যবহারকারী রিট্রাই করে, ফলশ্রুতিতে ডুপ্লিকেট চার্জ এবং ডুপ্লিকেট ইমেইল হতে পারে। ভাল ডিজাইনে চেকআউট সফল হয়, ইমেইল অনুরোধ কিউতে জমা হয়, এবং প্রোভাইডার ঠিক হলে একটি রিপ্লে জব ব্যাকলগ নিষ্কাশন করে।\n\n## স্কেল হলে ঘটা সাধারণ ফাঁদগুলো\n\nঅধিকাংশ আউটেজ এক চমকপ্রদ বাগ থেকে আসে না। সেগুলো আসে ছোট ছোট সিদ্ধান্ত থেকে যা প্রোটোটাইপে অর্থবহ ছিল এবং পরে অভ্যাসে পরিণত হয়েছে।\n\nএকটি সাধারণ ফাঁদ হল খুব দ্রুত মাইক্রোসার্ভিস-এ বিভক্ত হওয়া। আপনি এমন সার্ভিস পাবেন যা মূলত একে অপরকে কল করে, স্পষ্ট মালিকানা নেই, এবং পরিবর্তনের জন্য পাঁচটি ডিপ্লয় দরকার হয় একটির বদলে।\n\nআরেকটি ফাঁদ হল “eventual consistency” কে বিনা খরচে ছাড় দেওয়া। ব্যবহারকারীরা টার্ম নিয়ে যত্ন করে না; তারা যত্ন করে যে তারা Save ক্লিক করেছে এবং পরে পেজ পুরনো ডেটা দেখায়, বা একটি ইনভয়েস স্ট্যাটাস বারবার পিছিয়ে আসে। যদি আপনি দেরি মেনে নেন, তাহলে তাতে ইউজার ফিডব্যাক, টাইমআউট, এবং প্রতিটি স্ক্রিনে “ভালো পর্যায়” কী সে সংজ্ঞা থাকা দরকার।\n\nঅন্যান্য বারবার ঘটে এমন অপরাধীগণ: ইভেন্ট প্রকাশ করা কিন্তু রিপ্রসেসিং প্ল্যান না থাকা, অনিয়ন্ত্রিত রিট্রাই যা ঘটনার সময় লোড বাড়ায়, এবং প্রতিটি সার্ভিসকে একই ডাটাবেস স্কিমায় সরাসরি কথা বলতে দেওয়া যাতে একটি পরিবর্তন অনেক টিমকে ভেঙে দেয়।\n\n## “প্রোডাকশনে প্রস্তুত” বলার আগে দ্রুত চেক\n\n“প্রোডাকশন রেডি” হলো এমন কয়েকটি সিদ্ধান্ত যেগুলো রাতের মধ্যেও আপনি সহজে তুলে ধরতে পারেন। স্পষ্টতা মানে চৌকসতার চেয়ে ভাল।\n\nপ্রথমে আপনার সোর্স অফ ট্রুথের নাম বলুন। প্রতিটি প্রধান ডেটা টাইপ (গ্রাহক, সাবস্ক্রিপশন, ইনভয়েস, পারমিশন) জন্য সিদ্ধান্ত নিন চূড়ান্ত রেকর্ড কোথায় থাকে। যদি আপনার অ্যাপ “ট্রুথ” দুই জায়গা থেকে পড়ে, আপনি একদিন বিভিন্ন ব্যবহারকারীদের ভিন্ন উত্তর দেখাবেন।\n\nতারপর রিট্রাই দেখুন। ধরে নিন প্রতিটি গুরুত্বপূর্ণ অ্যাকশন শেষ পর্যন্ত দুইবার চলবে। একই রিকোয়েস্ট যদি দুইবার এসে লাগে, আপনি কি ডাবল চার্জ, ডাবল সেন্ড, বা ডাবল ক্রিয়েশন এড়াতে পারবেন?\n\nএকটি ছোট চেকলিস্ট যা বেশিরভাগ ব্যথা ধরা পড়ায়:\n\n- প্রতিটি ডেটা টাইপের জন্য সোর্স অফ ট্রুথ চিহ্নিত করা আছে ও কি কিছু ডেরাইভড\n- প্রতিটি গুরুত্বপূর্ণ রাইট রিট্রাই-সেফ (idempotency key বা ইউনিক কনস্ট্রেইন্ট)\n- আপনার অ্যাসিঙ্ক ওয়ার্ক অনন্তভাবে বাড়তে পারে না (আপনি ল্যাগ, oldest message age ট্র্যাক করেন এবং ব্যবহারকারী লক্ষ্য করার আগে অ্যালার্ট আছে)\n\n- পরিবর্তনের জন্য পরিকল্পনা আছে (রিভার্সিবল মাইগ্রেশন, ইভেন্ট ভার্সনিং)\n- আপনি ব্যাকআপ থেকে রিস্টোর ও রোলব্যাক অনুশীলন করেছেন\n\n## পরবর্তী ধাপ: একবারে একটা সিদ্ধান্ত নিন\n\nসিস্টেম ডিজাইন একটি দীর্ঘ তত্ত্বের তালিকা নয় বরং সংক্ষিপ্ত সিদ্ধান্তের তালিকা হলে স্কেলিং সহজ হয়।\n\nপরবর্তী একটি মাসে আপনি যেসব ৩–৫ টি সিদ্ধান্তের মুখোমুখি হবেন তা সাধারণ ভাষায় লিখে রাখুন: “আমরা কি ইমেইল পাঠানো ব্যাকগ্রাউন্ড জবে নিব?” “আমরা কি সামান্য স্টেল অ্যানালিটিক্স মেনে নেব?” “কোন অ্যাকশনগুলো অবিলম্বে কনসিস্টেন্ট হতে হবে?” সেই তালিকাটি ব্যবহার করে প্রোডাক্ট ও ইঞ্জিনিয়ারিংকে সমন্বয় করুন।\n\nএরপর একটি ওয়ার্কফ্লো বেছে নিন যা বর্তমানে synchronous এবং কেবল সেটাই async-এ রূপান্তর করুন। রসিদ, নোটিফিকেশন, রিপোর্ট, এবং ফাইল প্রসেসিং সাধারণ প্রথম পদক্ষেপ। পরিবর্তনের আগে ও পরে দুই জিনিস মাপুন: ব্যবহারকারীর মুখোমুখি ল্যাটেন্সি (পেজটি কি দ্রুত অনুভূত হয়েছিল?) এবং ব্যর্থতার আচরণ (রিট্রাই কি ডুপ্লিকেট বা বিভ্রান্তি তৈরি করেছিল?)\n\nযদি দ্রুত prototyping চান, Koder.ai (koder.ai) React + Go + PostgreSQL SaaS-এ কাজ করে দ্রুত পুনরাবৃত্তির সময় স্ন্যাপশট ও রোলব্যাক কাছে রেখে। মাপকাঠি সহজ: এক উন্নতি পাঠান, বাস্তব ট্রাফিক থেকে শিখুন, তারপর পরবর্তী সিদ্ধান্ত নিন।একটি প্রোটোটাইপ উত্তর দেয় “আমরা এটা তৈরি করতে পারি কি?” একটি SaaS উত্তর দিতে হবে “এটা ব্যবহারকারী, ডেটা, এবং ব্যর্থতার মধ্যে থাকলেও চলবে কি?”\n\nসবচেয়ে বড় পরিবর্তনগুলো হল এমনভাবে ডিজাইন করা যাতে সেগুলো সামলে নিতে পারে:\n\n- ধীর ডিপেনডেন্সি (ইমেইল, পেমেন্ট, ফাইল প্রক্রিয়াকরণ)\n- রিট্রাই ও ডুপ্লিকেটস\n- ডেটা যে বাড়ে ও জটিল হয়\n- কি নিশ্চিতভাবে সঠিক থাকা দরকার বনাম কি সামান্য স্টেলে থাকা মানা যাবে তা সম্পর্কে পরিষ্কার নিয়ম
একটি সীমানা বেছে নিন যা আপনি ব্যবহারকারীদের প্রতি প্রতিশ্রুতি দিচ্ছেন, তারপর পদক্ষেপগুলোর প্রভাব অনুযায়ী লেবেল দিন।\n\nপ্রথমে প্রতিবার সঠিক হতে হবে-এর তালিকা করুন:\n\n- টাকা নেওয়া/ফেরত দেওয়া\n- অ্যাক্সেস নিয়ন্ত্রণ এবং অ্যানটাইটেলমেন্ট\n- অ্যাকাউন্ট মালিকানা ও সিকিউরিটি অ্যাকশন\n\nতারপর ধীরগতিতে সঠিক হওয়া যায়-এ চিহ্ন দিন:\n\n- অ্যানালিটিক্স কাউন্টস\n- সার্চ ইনডেক্স\n- নোটিফিকেশন ও অ্যাক্টিভিটি ফিড\n\nএটা লিখে রাখুন যাতে সবাই একই নিয়ম অনুযায়ী তৈরি করে।
প্রতিটি “ফ্যাক্ট” কোথায় একবার রেকর্ড হবে এবং ফাইনাল হিসেবে বিবেচিত হবে সেটা বেছে নিন (ছোট SaaS-এ প্রায়ই Postgres)। এটিই আপনার source of truth।\n\nঅন্যান্য সবকিছু গতি বা সুবিধার জন্য ডেরাইভড। একটি ভাল পরীক্ষা: ডেরাইভড ডেটা যদি ভুল হয়ে যায়, আপনি কি source of truth থেকে সেটা পুনর্গঠন করতে পারবেন অনুমান বা আন্দাজ না করে?
যখন ব্যবহারকারী অবিলম্বে ফলাফল দেখতে চান এবং কাজ ছোট, তখন request-response ব্যবহার করুন।\n\nকাজটিকে async-এ নিয়ে যাবেন যখন সেটা পরে করা যাবে বা ধীর হতে পারে, যেমন:\n\n- ইমেইল পাঠানো\n- কার্ড চার্জ করা (প্রায়ই ভ্যালিডেশনের পরে)\n- রিপোর্ট জেনারেশন\n- ফাইল প্রসেসিং\n\nAsync রাখা আপনার API কে দ্রুত রাখে এবং ক্লায়েন্ট রিট্রাই থেকে টাইমআউট কমায়।
একটি কিউ হলো টু-ডু লিস্ট: প্রতিটি কাজ একবার একটি ওয়ার্কার দ্বারা করা উচিত (রিট্রাই সহ)।\n\nএকটি স্ট্রিম/লগ হলো ইভেন্টের ধারাবাহিক রেকর্ড: একাধিক কনজিউমার এটি রিপ্লে করতে পারে বা নতুন ফিচার তৈরির জন্য সাবস্ক্রাইব করতে পারে।\n\nপ্র্যাকটিক্যাল ডিফল্ট:\n\n- ব্যাকগ্রাউন্ড টাস্কের জন্য কিউ ব্যবহার করুন ("welcome email পাঠান")\n- রিপ্লে বা অডিট জন্য বিজনেস ইভেন্ট হলে স্ট্রিম/লগ ব্যবহার করুন (PaymentSucceeded)
গুরুত্বপূর্ণ অপারেশনগুলো idempotent করুন: একই রিকোয়েস্ট বারবার করলে একই আউটকাম ফিরে আসবে, দ্বিতীয় চার্জ বা দ্বিতীয় ইনভয়েস তৈরি হবে না।\n\nকমন প্যাটার্ন:\n\n- ক্লায়েন্ট প্রতিটি অ্যাকশনের জন্য একটি idempotency key পাঠায়\n- সার্ভার সেই key দিয়ে ফলাফল স্টোর করে\n- পুনরাবৃত্তি হলে মূল ফলাফলটি রিটার্ন করে\n\nএছাড়া যেখানে সম্ভব ইউনিক কনস্ট্রেইন্ট ব্যবহার করুন (যেমন, একটি অর্ডারের জন্য একটাই ইনভয়েস)।
একটা ছোট সেট স্থিতিশীল বিজনেস ফ্যাক্টস প্রকাশ করুন, অতীত কাল নাম ব্যবহার করুন—যেমন PaymentSucceeded বা SubscriptionStarted।\n\nইভেন্টগুলো রাখুন:\n\n- নির্দিষ্ট (“UserUpdated” ধরনের ক্যাচ-অল সেটা নয়)\n- কন্ট্রাক্ট হিসেবে টেকসই\n- সহজে বিবর্তনশীল (নতুন অপশনাল ফিল্ড যোগ করুন; ব্রেকিং হলে নতুন নাম/ভার্সন প্রকাশ করুন)\n\nএটা কনজিউমারদের অনুমান করতে বাধ্য করবে না কি ঘটেছে।
আপনার সিস্টেমে ব্যাকপ্রেশার দরকার হওয়ার সংকেতগুলো:\n\n- কিউ ব্যাকলগ কেবল বাড়ছে\n- ট্রাফিক স্পাইকের পরে ল্যাটেন্সি স্কাইরকেট করছে\n- টাইমআউটের কারণে রিট্রাই বেড়ে যাচ্ছে\n- একটি ধীর ডিপেনডেন্সি অনান্য এন্ডপয়েন্টকে ফেল করছে\n- ডাটাবেস সংযোগ সীমায় পৌঁছেছে\n\nশুরুতে যা করা উচিত:\n\n- ইউজার/এপিআই কী-ভিত্তিক রেট লিমিট\n- বাউন্ডেড কিউ (পরিষ্কার ড্রপ/ডিলে পলিসি সহ)\n- ব্যর্থ ডিপেনডেন্সির জন্য সার্কিট ব্রেকার\n- ইন্টারঅ্যাকটিভ রিকোয়েস্টকে প্রায়োরিটি দিন যাতে ব্যাকগ্রাউন্ড জবগুলো হার মানে
শুরুতে এমন বেসিক অবজারভেবিলিটি রাখুন যা ব্যবহারকারী কষ্টের সাথে মেলে:\n\n- প্রতিটি রিকোয়েস্টের জন্য একটি ID যা লগে দেখা যায় শেষ পর্যন্ত\n- এরর রেট, ল্যাটেন্সি, কিউ ডেপথ, এবং ধীর কুয়েরির মতো মেট্রিক্স\n- কিউগুলোর জন্য “oldest message age” এর অ্যালার্ট (শুধু সাইজ নয়)\n\nট্রেসিং যোগ করুন শুধুমাত্র যেখানে রিকোয়েস্ট সার্ভিস পার করে; সবকিছু ইনস্ট্রুমেন্ট করার আগে কি খুঁজছেন তা জানুন।
“প্রোডাকশন রেডি” মানে এমন সিদ্ধান্তের সেট যা আপনি রাত ২টায়ও দেখাতে পারেন। স্পষ্টতা চতুরতার চেয়ে ভাল।\n\nচেকলিস্ট:\n\n- প্রতিটি ডেটা টাইপের জন্য সোর্স অফ ট্রুথ কোথায় তা বলতে পারেন\n- প্রতিটি গুরুত্বপূর্ণ রাইট রিট্রাই-সেফ কি (idempotency key বা ইউনিক কনস্ট্রেইন্ট)?\n- অ্যাসিঙ্ক কাজ সীমাবদ্ধ ও মনিটর করা আছে (ল্যাগ/oldest message age)\n- রিভার্সিবল মাইগ্রেশন ও ইভেন্ট ভার্সনিংয়ের পরিকল্পনা আছে\n- ব্যাকআপ থেকে রিস্টোর প্র্যাকটিস করেছেন এবং রোলব্যাক দ্রুত করতে পারেন\n\nযদি আপনার প্ল্যাটফর্ম স্ন্যাপশট ও রোলব্যাক সাপোর্ট করে (যেমন Koder.ai), সেগুলোকে সানডে-অ্যাক্সিডেন্ট ট্রিক না করে নর্মাল রিলিজ অভ্যাস করুন।