মাল্টি-টিনেন্ট প্ল্যাটফর্মের জন্য ইনবাউন্ড ইমেল পার্সিং ওয়েবহুক সেটআপ করা

মাল্টি-টিনেন্ট প্ল্যাটফর্মের জন্য ইনবাউন্ড ইমেল পার্সিং ওয়েবহুক সেটআপ করা.

ইনবাউন্ড ইমেল প্রক্রিয়াকরণের স্থাপত্য ওভারভিউ

ইনবাউন্ড ইমেল পার্সিং কাঁচা SMTP স্ট্রিমগুলিকে আপনার মাল্টি-টিনেন্ট যোগাযোগের হাবের জন্য কাঠামোগত ওয়েবহুক পেলোডে রূপান্তরিত করে। যখন একজন সাব-টিনেন্ট প্রাপক একটি বার্তার উত্তর দেন, তখন MX রেকর্ডগুলি SMTP সেশনটিকে এজ ইনজেস্ট সার্ভারে রুট করে। পার্সিং পাইপলাইন হেডার, মাল্টিপার্ট MIME বডি এবং কাঁচা সংযুক্তিগুলি বের করে। এই ডেটা প্রসেসিং মডিউলটি প্রতিটি সাব-টিনেন্টের অভ্যন্তরীণ ডেটাবেস রাউটিং কী সনাক্ত করতে বার্তা আইডি এবং ইন-রেফারেন্স হেডার বিশ্লেষণ করে। কনসোল ড্যাশবোর্ড থেকে রিয়েল-টাইম পার্সিং মেট্রিকস ট্র্যাক করা যায়, যা ইমেল ডেলিভারি নিশ্চিত করতে সাহায্য করে।

DNS রেকর্ড এবং MX রাউটিং কনফিগার করা

নিরাপদে ইনবাউন্ড মেল রাউট করার জন্য প্রতিটি পরিচালিত পাঠানোর ডোমেনের জন্য সুনির্দিষ্ট DNS কনফিগারেশন প্রয়োজন। সাব-টিনেন্টগুলিকে আপনার প্ল্যাটফর্ম ইনজেস্ট এন্ডপয়েন্টের দিকে নির্দেশকারী MX রেকর্ডগুলির পাশাপাশি স্ট্যান্ডার্ড CNAME ভ্যালিডেটর প্রদান করতে হবে। যখন রিমোট মেল সার্ভার থেকে ইনকামিং সংযোগ আসে, তখন TLS হ্যান্ডশেক নিশ্চিত করে যে ডেটা ট্রানজিটে সুরক্ষিত রয়েছে। ভুল কনফিগারেশনের কারণে সৃষ্ট বাউন্স ইমেল বা সাময়িক ত্রুটিগুলি অবিলম্বে লগ করা হয় যাতে অপারেশনাল টিম তাৎক্ষণিকভাবে ডিএনএস আপডেট প্রয়োগ করতে পারে।

ওয়েবহুক পেলোডের ডিজাইন এবং নিরাপত্তা যাচাইকরণ

ওয়েবহুক সরবরাহের নির্ভরযোগ্যতা নির্ধারক পেলোড কাঠামো এবং শক্তিশালী এন্ডপয়েন্ট প্রমাণীকরণ মেকানিজমের উপর নির্ভর করে। প্রতিটি আউটগোয়িং ওয়েবহুকে HTTP হেডারে একটি HMAC-SHA256 স্বাক্ষর থাকে, যা গ্রহণকারী সাব-টিনেন্টের জন্য অনন্য একটি গোপন চাবি ব্যবহার করে গণনা করা হয়। নিরাপত্তা যাচাইকরণ পাস করতে এন্ডপয়েন্টটিকে অবশ্যই নির্দিষ্ট সময়ের মধ্যে রেসপন্স দিতে হবে। এছাড়া, ওটিপি (OTP) ভিত্তিক অতিরিক্ত যাচাইকরণ স্তর যোগ করা যেতে পারে যখন কোনো সংবেদনশীল সাব-টিনেন্ট অ্যাকশনের মাধ্যমে কনফিগারেশন পরিবর্তন করা হয়।

হারের সীমা এবং ব্যাকপ্রেশার পরিচালনা

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

অপারেশনাল ট্রাবলশুটিং এবং প্রয়োজনীয় সম্পদ

ওয়েবহুক সরবরাহের ব্যর্থতা নির্ণয় করার জন্য কাঠামোগত লগ পরিদর্শন এবং এন্ডপয়েন্ট উপলব্ধতার সুনির্দিষ্ট যাচাইকরণ প্রয়োজন। অপারেটরগণ ব্যর্থ ওয়েবহুক ইভেন্টগুলি পুনরায় চালাতে ডেভেলপার কনসোল ব্যবহার করেন। লগগুলিতে প্রতিটি এইচটিটিপি স্থিতি কোড, প্রতিক্রিয়ার সময় এবং নেটওয়ার্ক টাইমআউট বিস্তারিতভাবে রেকর্ড করা হয়। ডিএলআর (DLR) ট্র্যাকিং ব্যবহার করে ডেলিভারি ট্রাবলশুটিং আরও দ্রুত করা যায়, যা ডাউনস্ট্রিম নেটওয়ার্কের যেকোনো অসংগতি বা সংযোগ বিচ্ছিন্ন হওয়ার সমস্যা চিহ্নিত করতে সাহায্য করে।

সম্পর্কিত: ইমেল পাইলট সপ্তাহ: আসল প্রাপকদের আগে লাইভ অথ চেক · এপিআই পাইলট সপ্তাহ: লাইভ ট্রাফিকে কি এবং ওয়েবহুক · পাইলট থেকে প্রোডাকশনে API হার সীমা.

IOSOR দিয়ে শুরু করুন

MX-কে পার্স হোস্টে নির্দেশ করুন এবং প্রতি-টেন্যান্ট শেয়ার্ড সিক্রেটসহ inbound webhook URL তৈরি করুন। 2xx ফেরানোর আগে payload সংরক্ষণ করুন। message-id দিয়ে রিপ্লে করুন যাতে webhook পুনঃচেষ্টা দ্বিতীয় টিকিট না খোলে। প্রমাণ করুন একটি inbound বার্তা ledger-এ সেই টেন্যান্টের সারিতে পৌঁছায়।

IOSOR সারাংশ

ঝরে পড়া payload নিয়ে HTTP 200 নীরব ব্যর্থতা। লেখার পরে ACK, আগে নয়।

করুন: আগে সংরক্ষণ, তারপর 2xx; 5xx-এ webhook আবার চেষ্টা করুন। করবেন না: পার্সার এখনও বাফার করলে 200-এ ACK দেবেন না, টেন্যান্টদের মধ্যে এক webhook সিক্রেট ভাগ করবেন না।