ব্যাক এন্ড ডেভেলপারসাক্ষাৎকারের উত্তর

আমি REST নীতিগুলি অনুসরণ করি: রিসোর্সগুলো হলো নাম (কর্মপদ নয়), URI গুলো হায়ারার্কিক্যাল এবং রিসোর্স সম্পর্কগুলো উপস্থাপন করে, HTTP মেথডগুলো অর্থপূর্ণভাবে ব্যবহার করা হয় (GET — পড়া, POST — তৈরি, PUT/PATCH — আপডেট, DELETE — মুছে ফেলা)। আমি শুরু থেকেই API-versioning রাখি (/v1/) যাতে ব্রেকিং পরিবর্তন এড়ানো যায়। আমি সঙ্গতিপূর্ণ রেসপন্স ফরম্যাট, এরর কোড এবং পেজিনেশন প্যাটার্ন ডিজাইন করি। OpenAPI/Swagger দিয়ে ডকুমেন্ট করি। ডিজাইনের সময় ক্লায়েন্টের প্রয়োজনগুলো বিবেচনা করি — একটি টেকনিক্যালভাবে সঠিক কিন্তু ব্যবহার করার দরিদ্র API খারাপ। এছাড়াও আমি রেট লিমিটিং, অথেন্টিকেশন এবং ইনপুট ভ্যালিডেশনকে প্রথম-শ্রেণীর API উদ্বেগ হিসেবে বিবেচনা করি।

আমি অ্যাক্সেস প্যাটার্নগুলোর উপর ভিত্তি করে স্কিমা ডিজাইন করি — ডিফল্টভাবে নরমালাইজ করি, এবং যখন কুয়েরি পারফরম্যান্স দাবি করে তখন ডিনরমালাইজ করি। আমি স্ট্র্যাটেজিকভাবে ইনডেক্স ব্যবহার করি: প্রতিটি ধীর কুয়েরির জন্য explain plan দেখে ইনডেক্স যুক্ত করা হয় সিলেক্টিভিটি এবং কুয়েরি ফ্রিকোয়েন্সি অনুযায়ী। আমি N+1 কুয়েরি এড়াতে ডাটা লেয়ারে eager loading ডিজাইন করি। মাইগ্রেশন সাবধানে লিখি — যেখানে সম্ভব ব্যাকওয়ার্ড-কমপ্যাটিবল পরিবর্তন করি, এবং ব্রেকিং স্কিমা পরিবর্তনের জন্য ব্লু-গ্রীন ডিপ্লয়মেন্ট কৌশল ব্যবহার করি। এছাড়া আমি ডেটা ইন্টেগ্রিটির জন্য ডিজাইন করি: foreign key constraints, not-null constraints, এবং check constraints ডাটাবেস স্তরে কনসিস্টেন্সি নিশ্চিত করে।

আমি শুরু থেকেই স্টেটলেস সার্ভিস ডিজাইন করি — স্টেট ডাটাবেস বা ক্যাশে থাকে, অ্যাপ্লিকেশন মেমরিতে নয়। আমি অ্যাসিঙ্ক প্রসেসিং ব্যবহার করি (মেসেজ কিউ: RabbitMQ, Kafka, SQS) এমন অপারেশনগুলোর জন্য যেগুলো synchronous হওয়া প্রয়োজন নয়। উপযুক্ত লেয়ারে আগ্রাসিভ কেশিং করি: ডাটাবেস কুয়েরি ফলাফল (Redis), গণনামূলক অগ্রিগেশন, এবং স্ট্যাটিক রিসোর্স। আমি APIs-কে হরাইজন্টালি স্কেলাবল রাখি এবং এমন managed services (RDS, ElasticCache) পছন্দ করি যা স্বাধীনভাবে স্কেল করতে পারে। আমি রেট লিমিটিং এবং ব্যাকপ্রেসার হ্যান্ডলিংও ডিজাইন করি — লোডের সময় সার্ভিসগুলোকে সুন্দরভাবে অবনতি (graceful degradation) করার যোগ্য করতে হয়।

অথেন্টিকেশন: ইউজার অথের জন্য OAuth 2.0 / OIDC, সার্ভিস-টু-সার্ভিসের জন্য API কী বা JWT। আমি সব ইনপুট ভ্যালিডেট ও স্যানিটাইজ করি — ইউজার ইনপুট থেকে সরাসরি SQL তৈরি করা হয় না। আমি অপব্যবহার রোধে রেট লিমিটিং ও থ্রটলিং বাস্তবায়ন করি। সবস্থানে HTTPS/TLS ব্যবহার করি এবং সার্টিফিকেট ভ্যালিডেশন জোরদার করি। ন্যূনতম-প্রিভিলেজ নীতি অনুসরণ করি: প্রতিটি সার্ভিস ও ইউজারকে প্রয়োজনীয় সর্বনিম্ন অনুমতি দিই এবং অনুমতির ব্যবহার অডিট করি। CI-তে ডিপেন্ডেন্সিগুলো দুর্বলতার জন্য স্ক্যান করি (OWASP Dependency-Check, Snyk)। এবং আমি সেন্ট্রালাইজডভাবে সিকিউরিটি ইভেন্ট লগ করি — ব্যর্থ অথেন্টিকেশন, প্রিভিলেজ এসকালেশন ইত্যাদি মনিটরিং-এর জন্য।

আমার নীতি হচ্ছে: এররগুলো লগ করা, শ্রেণীভুক্ত করা এবং অর্থপূর্ণভাবে রিটার্ন করা উচিত। আমি উপযুক্ত লগ লেভেলে স্ট্রাকচার্ড লগিং (JSON) ব্যবহার করি যাতে লগগুলো কোয়েরি করা যায়। আমি ডিস্ট্রিবিউটেড ট্রেসিং (OpenTelemetry) বাস্তবায়ন করি যাতে রিকোয়েস্টগুলো সার্ভিস জুড়ে অনুসরণ করা যায়। আমি API জুড়ে ত্রুটি কোডগুলো কনসিস্টেন্টভাবে সংজ্ঞায়িত ও ডকুমেন্ট করি। আমি কেবল প্রযুক্তিগত মেট্রিক (যেমন CPU) নয়, এরর রেটের অস্বাভাবিকতার ওপরও অ্যালার্টিং সেট করি। মাইক্রোসার্ভিস আর্কিটেকচারে, আমি নির্ভরতা degrade হলে cascade ব্যর্থতা আটকাতে সার্কিট ব্রেকার (Resilience4j, Hystrix) বাস্তবায়ন করি।

আমি উভয়ই তৈরি ও রক্ষণাবেক্ষণ করেছি। মনোলিথকে কমই মূল্যায়ন করা হয়: এগুলো বিকাশ, টেস্ট এবং ডিপ্লয় করার জন্য সহজ, এবং বেশিরভাগ টিমকে নির্দিষ্ট স্কেলিং বা টিম কোঅর্ডিনেশন সীমা না পেয়ে গেলে মাইক্রোসার্ভিসের প্রয়োজন হয় না। যখন আমি মাইক্রোসার্ভিসে স্থানান্তর করেছি, তখন Strangler Fig প্যাটার্ন প্রয়োগ করেছি — একটি কাজ করা মনোলিথ থেকে ধাপে ধাপে সার্ভিসগুলো বের করে আনা, একবারের বড়-বিস্ফোরণভিত্তিক বিভাজনের বদলে। মাইক্রোসার্ভিসগুলো অপারেশনাল জটিলতা বাড়ায় (সার্ভিস ডিসকভারি, ডিস্ট্রিবিউটেড ট্রেসিং, নেটওয়ার্ক ফেইলিউর মোড, সার্ভিসগুলোর মধ্যে ডেটা কনসিস্টেন্সি) — আমি শুধুমাত্র তখনই সেই জটিলতাকে গ্রহণ করি যখন এর সুবিধাগুলো স্পষ্টভাবে অধিক হয়।

আমি বিজনেস লজিকের জন্য আলাদা করে ইউনিট টেস্ট লিখি (ডাটাবেস ও এক্সটার্নাল ডিপেন্ডেন্সি মক করে)। আমি ইন্টিগ্রেশন টেস্ট লিখি যা সার্ভিসকে একটি বাস্তব (টেস্ট) ডাটাবেসের বিরুদ্ধে যাচাই করে — এগুলো পুরো রিকোয়েস্ট-রেসপন্স চক্র পরীক্ষা করে এবং ইউনিট টেস্টে ধরা না পড়া SQL ত্রুটি, কুয়েরি পারফরম্যান্স ইস্যু, ও ডেটা মেপিং সমস্যা ধরতে সাহায্য করে। যেখানে সার্ভিসগুলো অন্যান্য টিম দ্বারা ব্যবহৃত হয়, সেখানে আমি কন্ট্র্যাক্ট টেস্টিং (Pact) ব্যবহার করি। পারফরম্যান্স-ক্রিটিক্যাল এন্ডপয়েন্টগুলোর জন্য লোড টেস্ট (k6, Locust) লিখি। টেস্ট কভারেজ তখনই অর্থবহ যখন টেস্টগুলো বাস্তব ব্যর্থতা ধরা পড়াবে।

আমি RabbitMQ এবং Apache Kafka ব্যবহার করে ইভেন্ট-চালিত সিস্টেম ডিজাইন করেছি। আমি ট্রেড-অফগুলো বুঝি: at-least-once বনাম exactly-once ডেলিভারি, কনসিউমার গ্রুপ প্যাটার্ন, dead letter queues, এবং মেসেজ অর্ডারিং গ্যারান্টি। আমি মেসেজ স্কিমাগুলো সাবধানে ডিজাইন করি — প্রোডাকশনে ব্যাকওয়ার্ড-কমপ্যাটিবল স্কিমা ইভোলিউশন অপরিহার্য। আমি idempotent কনসিউমার বাস্তবায়ন করি যাতে ডুপ্লিকেট মেসেজ ডেটা নষ্ট না করে। অপারেশনাল মেট্রিক হিসেবে কিউ গভীরতা (queue depth) এবং কনসিউমার ল্যাগ মনিটর করি। ইভেন্ট-চালিত আর্কিটেকচারে দুর্দান্ত স্কেলেবিলিটি ও ডিসকপলিং সম্ভব, কিন্তু এর জন্য নিয়মিত স্কিমা ম্যানেজমেন্ট ও ফেলিওর হ্যান্ডলিং প্রয়োজন।