ভেন্যু ইন্টিগ্রেশনের জন্য Webhook vs API: একটি ব্যবহারিক নির্দেশিকা
ভেন্যু এবং হসপিটালিটি টিমগুলির জন্য Webhook vs API-এর ব্যাখ্যা। লেটেন্সি, বিশ্বস্ততা, সুরক্ষা তুলনা করুন এবং WiFi, POS, বুকিং ও স্টে-এর জন্য কোনটি বেছে নেবেন তা দেখুন।
আপনি একটি মাল্টি-সাইট রোলআউটের ছয় সপ্তাহে রয়েছেন। WiFi ক্যাপচার লাইভ রয়েছে, ক্যাশ রেজিস্টারগুলি সংযুক্ত, বুকিং আসছে, এবং মার্কেটিং একটি সাধারণ জিনিস চায়। যখন একজন অতিথি কেনাকাটা করেন, বুক করেন, WiFi-এ যোগ দেন বা চেক আউট করেন, সঠিক মুহূর্তে সঠিক বার্তাটি পাঠান। এরপর একটি পারচেজ ওয়েবহুক দুবার আসে এবং দুটি একক ব্যবহারের অফার ইস্যু করে। রিসিভার রিস্টার্টের সময় একটি WiFi সাইন-ইন অদৃশ্য হয়ে যায়। কেউ খারাপ ভেন্ডর বেছে নেয়নি। আপনি ওয়েবহুক বনাম API-কে দুটি পরিবর্তনযোগ্য পাইপের মধ্যবর্তী পছন্দ হিসেবে বিবেচনা করেছেন, এবং প্রোডাকশনে সেই পার্থক্য সামনে চলে এসেছে।
সূচিপত্র
- কেন ভেন্যু টিমগুলো এই নির্বাচনটি ভুল করে
- Webhooks এবং APIs প্রকৃতপক্ষে যা করে
- গুরুত্বপূর্ণ মানদণ্ডগুলোর ভিত্তিতে Webhooks এবং APIs-এর তুলনা
- প্রতিটি ভেন্যু ইভেন্টের জন্য কোন প্যাটার্নটি উপযুক্ত
- এমন একটি রিসিভার ডিজাইন করা যা প্রোডাকশনে কোনো ত্রুটি ঘটায় না
- প্রকৃত পছন্দ কেন Webhook এর সাথে API
কেন ভেন্যু টিমগুলো এই সিদ্ধান্তে ভুল করে
একটি রেস্তোরাঁ গ্রুপ সাইন-ইনের জন্য Purple WiFi, রসিদের জন্য Square বা Epos Now, রিজার্ভেশনের জন্য ResDiary এবং রুম ব্যবসার জন্য Mews ব্যবহার করে। প্রতিটি ভেন্ডর দাবি করে যে তারা ইন্টিগ্রেশন সমর্থন করে। কিন্তু প্রত্যেকের কথার অর্থ কিছুটা আলাদা। কেউ ইভেন্ট পুশ করে, কেউ পোল করার আশা করে, আবার কেউ বিভিন্ন ফিল্ড এবং রিট্রাই আচরণ সহ উভয়ই করে।
টিম প্রথমে দ্রুততম পথটি সংযুক্ত করে। একটি POS বিক্রি অফার সহ একটি ধন্যবাদ জার্নি ট্রিগার করে। POS যথেষ্ট দ্রুত রেসপন্স পায় না, পুনরায় চেষ্টা করে, এবং রিসিভার একই বিক্রি আবার প্রসেস করে কারণ এটি কখনো ইভেন্ট আইডি সংরক্ষণ করেনি। গেস্ট দুটি বার্তা পান এবং, আরও খারাপভাবে, দুটি রিডিমযোগ্য কোড পান।
মিসড ইভেন্ট হলো তুলনামূলক শান্ত কিন্তু মারাত্মক ব্যর্থতা
একই উইকএন্ডে, একটি ডিপ্লয়মেন্টের কারণে রিসিভার অফলাইনে থাকে। WiFi জয়েনিং ডেটা প্রেরকের কাছে কিছুক্ষণের জন্য কিউতে জমা হয়, তারপর প্রচেষ্টার সীমা শেষ হয়ে যায়। সেগুলি পুনরুদ্ধার করার জন্য কোনো শিডিউল করা API রিড নেই, তাই সেই গেস্টরা কখনোই ওয়েলকাম জার্নিতে প্রবেশ করতে পারেন না। রিপোর্টিং স্রেফ কম মনে হয়, ভাঙা নয়। নিখোঁজ সাইন-ইনের জন্য কেউ কাউকেই অ্যালার্ট পাঠায় না।
ব্যবহারিক নিয়ম: একটি webhook-কে কোনো কিছু ঘটতে পারে এমন একটি সিগন্যাল হিসেবে বিবেচনা করুন, বর্তমান অবস্থার প্রমাণ হিসেবে নয়। যেকোনো কিছু পাঠানো, ইস্যু করা বা রিডিম করার আগে বর্তমান অবস্থা প্রমাণ করুন।
এগুলি কোনো ব্যতিক্রমী কেস নয়। এগুলো ডিস্ট্রিবিউটেড সিস্টেমের স্বাভাবিক আচরণ, যেমনটি guidance on combining webhooks with APIs for recovery-তে বলা হয়েছে। ডেলিভারি সাধারণত at least once হয়, ইভেন্টগুলি দেরিতে বা ভুল ক্রমে আসতে পারে এবং আপনি যদি পুনর্মিলনের ব্যবস্থা না করেন তবে একটি অনুপস্থিত রিসিভার তথ্যের ব্যবধান তৈরি করে।
ভেন্যু টিমগুলো তিনটি বোধগম্য কারণে এটি ভুল করে থাকে।
- তারা জিজ্ঞাসা করে কোন টুলটি সেরা: কার্যকর প্রশ্ন হলো প্রতিটি ইভেন্ট, WiFi জয়েন, POS সেল, বুকিং বা চেকআউটের লেটেন্সি প্রয়োজন এবং ভুলের খরচের কথা বিবেচনা করে কোনটি কোন প্যাটার্নের সাথে খাপ খায়।
- তারা পেলোডকে বিশ্বাস করে: একটি পেলোড হলো পাঠানোর সময়ের একটি স্ন্যাপশট। কয়েক ঘণ্টা পর পুনরায় চেষ্টার আগে সম্মতি, যোগ্যতা এবং খরচ পরিবর্তিত হতে পারে।
- তারা রিকভারি এড়িয়ে যায়: হ্যাপি-পাথ ডেমোগুলিতে ডুপ্লিকেট ডেলিভারি, রিঅর্ডার করা বা শনিবারের পরিষেবার সময় রিসিভার ডাউন থাকার মতো বিষয়গুলি দেখানো হয় না।
- API নিরাপত্তা: ক্লায়েন্টের প্রতিটি অনুরোধ প্রমাণীকরণের ওপর কেন্দ্র করে কাজ করে। Webhook নিরাপত্তা জাল, পুনরায় প্রেরিত, ভুল বিন্যাসের এবং ডুপ্লিকেট বার্তাগুলির বিরুদ্ধে একটি পাবলিক এন্ডপয়েন্টকে রক্ষা করার সুযোগ যোগ করে, যেমনটি webhook বনাম API নিরাপত্তার ওপর SuprSend নির্দেশিকায় ব্যাখ্যা করা হয়েছে। এর অর্থ হলো র' (raw) অনুরোধে সাইন করা, টাইমস্ট্যাম্পের তাজাত্ব যাচাই করা, কনস্ট্যান্ট-টাইম তুলনা ব্যবহার করা, HTTPS বলবৎ করা এবং প্রসেসিংকে আইডেমপোটেন্ট করা।
এটি রেস্তোরাঁ, হোটেল এবং রিটেইল ভেন্যুগুলির IT, ডেটা এবং CRM লিডদের জন্য একটি কার্যকরী নির্দেশিকা। আপনি মূল মেকানিক্স, মানদণ্ড-ভিত্তিক তুলনা, ইভেন্ট-ভিত্তিক সুপারিশ এবং একটি রিসিভার ডিজাইন পাবেন যা যেকোনো মাল্টি-সাইট লঞ্চের আগে পর্যালোচনা করা উচিত। এখানে লক্ষ্য webhook vs API-এর মধ্যে কোনো বিজয়ী ঘোষণা করা নয়। লক্ষ্য হলো ডুপ্লিকেট ক্যাম্পেইন এবং মিস হওয়া জার্নি বন্ধ করা।
Webhook এবং API প্রকৃতপক্ষে কী করে
কে কলটি শুরু করছে তা দিয়ে শুরু করুন। সেই একটি মাত্র তথ্যই পরবর্তী বেশিরভাগ ট্র্যাড-অফগুলো ব্যাখ্যা করে।
একটি API একটি পুল মডেল ব্যবহার করে। যখন ডেটার প্রয়োজন হয় বা কোনো কাজ সম্পাদন করতে চায়, তখন আপনার ক্লায়েন্ট একটি HTTP অনুরোধ পাঠায় এবং সার্ভার সাড়া দেয়। একটি webhook একটি পুশ মডেল ব্যবহার করে। একটি কেনাকাটা, বুকিং, অপ্ট-ইন বা অ্যাকাউন্ট আপডেটের মতো কোনো ঘটনা ঘটলে সোর্স সিস্টেমটি আপনার পূর্ব-কনফিগার করা এন্ডপয়েন্টে একটি HTTP অনুরোধ পাঠায়। API প্রোভাইডার অ্যাডপশনের ওপর Svix-এর State of Webhooks গবেষণায় এই পার্থক্যটি তুলে ধরা হয়েছে।
ভেন্যুর এই অ্যানালজিটি বেশ ভালোভাবেই মিলে যায়। API হলো এমন, যেখানে আপনি যখন চান তখন ওয়েটারকে মেনুটি দেওয়ার জন্য অনুরোধ করছেন। আর ওয়েবহুক হলো ওয়েটার নিজে থেকেই আপনার খাবার তৈরি হয়ে গেলে তা আপনার কাছে নিয়ে আসা, কোনো সংকেত দেওয়া ছাড়াই।
আপনি যে মেকানিক্স কনফিগার করছেন
উভয় প্যাটার্নই HTTP ব্যবহার করে, সাধারণত JSON পেলোড বহন করে, হেডারে মেটাডাটা পাস করে এবং রেসপন্স কোডের মাধ্যমে সফলতা বা ব্যর্থতা জানায়। এক্ষেত্রে দিকটি বিপরীত হয়, এবং সাথে অপারেশনের দায়িত্বও। API-এর ক্ষেত্রে, আপনি ক্রেডেনশিয়াল ধরে রাখেন, সময় বেছে নেন এবং পেজিনেশন ও রেট লিমিট পরিচালনা করেন। ওয়েবহুকের ক্ষেত্রে, আপনি একটি পাবলিকলি অ্যাক্সেসযোগ্য URL উন্মুক্ত করেন, আপনার দ্বারা শুরু না হওয়া ইনকামিং ট্রাফিক প্রমানীকৃত করেন এবং নিয়ন্ত্রণে না থাকা লোডের অধীনে দ্রুত রেসপন্স করতে বাধ্য থাকেন।
- POS সেল: কোনো লেনদেন সম্পন্ন হলে টিল একটি webhook পাঠায়, তাই প্রতিটি টিল পোলিং না করেই একটি রসিদ বা ফিডব্যাক জার্নি শুরু করা যেতে পারে।
- অবস্থানের ইতিহাস: অতিথির অতীতের অবস্থান সংগ্রহ করতে, চেকআউট মেলাতে বা মিস হওয়া সপ্তাহের তথ্য ব্যাকফিল করতে আপনার প্ল্যাটফর্ম PMS API কল করে।
- সেগমেন্ট রিফ্রেশ: প্রতিটি ফিল্ড পরিবর্তনে প্রতিক্রিয়া জানানোর বদলে একটি মার্কেটিং প্ল্যাটফর্ম একটি নির্দিষ্ট সময়সূচী অনুযায়ী API-এর মাধ্যমে আপডেট করা রেকর্ডগুলি পুল করে।
এগুলো পরিপূরক লেয়ার, বিকল্প নয়। ১০০টি প্রতিষ্ঠিত API প্রোভাইডারের ওপর করা গবেষণায় দেখা গেছে যে ২০২৩ সালের গবেষণায় ৮৩% একটি ওয়েবহুক সার্ভিস অফার করেছে, এবং পরবর্তী একটি রিপোর্টে এটি ৮৫%-এ উন্নীত হওয়ার কথা বলা হয়েছে, যা State of Webhooks গবেষণায় নথিভুক্ত রয়েছে। প্রোভাইডাররা API-কে ওয়েবহুক দিয়ে প্রতিস্থাপন করছে না। তারা এর ওপর ইভেন্ট ডেলিভারি যুক্ত করছে।
পুশ সাইড এমন কিছু বাধ্যবাধকতাও নিয়ে আসে যা পুল সাইডে কখনোই থাকে না। একটি ওয়েবহুক এন্ডপয়েন্টকে অবশ্যই স্বাক্ষর যাচাই করতে হবে, ডুপ্লিকেট ডেলিভারি সহ্য করতে হবে এবং পরবর্তী মেলানোর জন্য প্রতিটি ইভেন্ট লগ করতে হবে, কারণ আপনি প্রস্তুত থাকুন বা না থাকুন, সোর্স পুনরায় ফায়ার করবে।
আপনি যদি শেয়ার্ড ইনফ্রাস্ট্রাকচারের মাধ্যমে উভয়ই রাউট করেন, তবে GoReplay-এর what is an API gateway নিবন্ধটি বোঝা গুরুত্বপূর্ণ, কারণ গেটওয়েগুলি প্রায়শই API ট্র্যাফিকের জন্য প্রমাণীকরণ, রেট লিমিটিং এবং রাউটিং পরিচালনা করে, যেখানে webhook রিসিভারগুলির সামনে নিজস্ব ভেরিফিকেশন এবং কিউইংয়ের প্রয়োজন হয়।
কোনো ডিজাইন চূড়ান্ত করার আগে এটি একটি হোয়াইটবোর্ডে আঁকুন। প্রতিটি তীরে সূচনাকারীকে চিহ্নিত করুন। যদি আপনার দল বলতে না পারে যে WiFi এ যুক্ত হওয়ার জন্য বা অবস্থানের ইতিহাস খোঁজার জন্য কে কাকে কল করে, তবে আপনি ভেন্ডরদের সাথে আলোচনা করার জন্য প্রস্তুত নন।
গুরুত্বপূর্ণ মানদণ্ড জুড়ে Webhook এবং API-এর তুলনা
সাধারণ সুবিধা এবং অসুবিধার তালিকা ভুলে যান। দিকনির্দেশনা, লেটেন্সি, রিকোয়েস্ট ভলিউম, ব্যর্থতার আচরণ, সিকিউরিটি এক্সপোজার এবং গভর্নেন্সের বিরুদ্ধে উভয় প্যাটার্ন মূল্যায়ন করুন। নিচের চার্টটি বিস্তারিত টেবিলের আগে দৃশ্যমানভাবে ছয়টি মানদণ্ড তুলে ধরে।
ইন্টিগ্রেশন মানদণ্ড জুড়ে Webhook বনাম API
| মানদণ্ড | Webhook | API |
|---|---|---|
| ট্র্যাফিকের দিক | কোনো ইভেন্টে সোর্স আপনার এন্ডপয়েন্টে পুশ করে | চাহিদা অনুযায়ী ক্লায়েন্ট সোর্স থেকে ডেটা পুল করে |
| ল্যাটেন্সি | প্রায় রিয়েল টাইম, নিচের তুলনায় এক সেকেন্ডের কম হিসেবে উল্লেখ করা হয়েছে | আপনার পোলিং ইন্টারভাল দ্বারা সীমাবদ্ধ |
| রিকোয়েস্ট ভলিউম | মূলত পরিবর্তন ঘটলেই রিকোয়েস্ট পাঠায় | কোনো পরিবর্তন না হলেও বারবার কল করা হয় |
| ব্যর্থতা এবং রিকভারি | অন্তত একবার, পুনরায় চেষ্টা, ডুপ্লিকেটের সম্ভাবনা থাকে | ক্লায়েন্ট যেকোনো সময় পুনরায় চেষ্টা করতে পারে, সহজ মেলানো সম্ভব |
| সিকিউরিটি এক্সপোজার | পাবলিকভাবে অ্যাক্সেসযোগ্য রিসিভার, ভুয়া ও রিপ্লে করা মেসেজের ঝুঁকি থাকে | প্রতিটি ক্লায়েন্ট রিকোয়েস্ট অথেন্টিকেট এবং অথরাইজ করুন |
| গভর্ন্যান্স | সিগনেচার চেক, অ্যাপেন্ড-অনলি লগ, ডেড-লেটার হ্যান্ডলিং | স্কোপ, রেট লিমিট, রিড ও রাইটের অডিট |
ল্যাটেন্সি এবং ভলিউমের সারিতেই পোলিংয়ের গণনা কঠিন হয়ে ওঠে। ওয়েবহুক এবং পোলিংয়ের তুলনা করে Hook0 এর নথিভুক্তকরণের একটি প্রতিনিধিত্বমূলক তুলনায়, ৬০ সেকেন্ডের পোলিং গড়ে ৩০ সেকেন্ডের বিলম্ব তৈরি করে এবং একটি উচ্চ ভলিউম সিনারিওতে প্রতি সেকেন্ডে একবার চেক করার সময় প্রতিদিন প্রায় ১৪.৪ মিলিয়ন API কল তৈরি করে। একই তুলনা অনুসারে, পোলিং কমিয়ে ৫ সেকেন্ডে আনলে গড়ে ২.৫ সেকেন্ডের বিলম্ব হয় কিন্তু ট্র্যাফিক বেড়ে প্রতিদিন প্রায় ১৭২.৮ মিলিয়ন কলে পৌঁছায়। এগুলি সিনারিওভিত্তিক গণনা, সার্বজনীন বেঞ্চমার্ক নয়, তাই আপনার নিজের অঞ্চলে প্রোভাইডারের ল্যাটেন্সি, ইভেন্টের ফ্রিকোয়েন্সি এবং রেট লিমিট মেপে নিন। তবে মূল বিষয়টি স্পষ্ট। কম খরচে পোলিং করে রিয়েল টাইম সুবিধা পাওয়া সম্ভব নয়।
ব্যর্থতা এবং পুনরুদ্ধার উভয় দিকেই কাজ করে। পোলিং সাধারণ এবং পুনরুদ্ধারযোগ্য। একটি ফেচ ব্যর্থ হলে, আপনি আবার ফেচ করেন এবং মিলিয়ে নেন। ওয়েবহুকের জন্য কিউইং, ব্যাকপ্রেসার কন্ট্রোল এবং রিপ্লে হ্যান্ডলিং প্রয়োজন কারণ প্রেরক ঠিক করে যে কখন ট্র্যাফিক আসবে, যার মধ্যে আপনার সবচেয়ে ব্যস্ততম সার্ভিসের সময় বা আপনার ডিপ্লয়মেন্ট উইন্ডোও অন্তর্ভুক্ত।
সিকিউরিটিতে যাওয়ার আগে নিচের এই নির্দেশিকাটি ডিরেকশন এবং টাইমিংয়ের পার্থক্যকে আরও স্পষ্ট করবে।
নিরাপত্তার ঝুঁকি হলো অসমেত, একই কাজের দুটি সংস্করণ নয়। API নিরাপত্তা প্রতিটি ক্লায়েন্ট অনুরোধ প্রমাণীকরণের ওপর ভিত্তি করে কাজ করে। Webhook নিরাপত্তা জাল, পুনরায় প্রেরিত, ভুল বিন্যাসের এবং ডুপ্লিকেট বার্তাগুলির বিরুদ্ধে একটি পাবলিক এন্ডপয়েন্টকে রক্ষা করার বৈশিষ্ট্য যোগ করে, যেমনটি webhook বনাম API নিরাপত্তার ওপর SuprSend নির্দেশিকায় ব্যাখ্যা করা হয়েছে। এর অর্থ হলো র' (raw) অনুরোধে সাইন করা, টাইমস্ট্যাম্পের তাজাত্ব যাচাই করা, কনস্ট্যান্ট-টাইম তুলনা ব্যবহার করা, HTTPS বলবৎ করা এবং প্রসেসিং আইডেমপোটেন্ট করা।
গভর্নেন্স এটি থেকেই আসে। জিজ্ঞাসা করুন যে একটি ইনকামিং ইভেন্ট নিরাপদে একটি গেস্ট রেকর্ড পরিবর্তন করতে পারে কিনা বা একাধিক সাইট, টাইম জোন এবং অনুমোদন নিয়মের মাধ্যমে একটি সেন্ড ট্রিগার করতে পারে কিনা। আপনি যখন Purple Engage ইন্টিগ্রেশন বা অন্য কোনো ডিরেক্টরি পর্যালোচনা করছেন, তখন কেবল একটি লোগো আছে কিনা তা দেখে থামবেন না। জিজ্ঞাসা করুন কোন ইভেন্টগুলি পুশ করে, কোনটি আপনাকে পুল করতে হবে, পুনরায় চেষ্টা করার প্রক্রিয়া কেমন দেখায় এবং কোনো বিভ্রাটের পর একটি রেকর্ড যে সঠিক তা আপনি কীভাবে প্রমাণ করবেন।
কোন প্যাটার্নটি প্রতিটি ভেন্যু ইভেন্টের সাথে মানানসই
দুটি প্রশ্নের ভিত্তিতে প্রতিটি ইভেন্ট মূল্যায়ন করুন। আপনাকে কতটা দ্রুত প্রতিক্রিয়া জানাতে হবে এবং পুরনো বা ডুপ্লিকেট ডেটার ভিত্তিতে কাজ করার খরচ কত? নিচের ছবিটি একটি দরকারী অনুস্মারক যে এই ইভেন্টগুলি কোনো ডেটাবেসের সারি হিসেবে নয়, বরং কোনো ভেন্যুতে শারীরিক মুহূর্ত হিসেবে শুরু হয়।
WiFi সাইন-ইন
ট্রিগার হিসেবে একটি ওয়েবহুক ব্যবহার করুন। একজন অতিথি যিনি এইমাত্র যোগ দিয়েছেন তিনি এখনই সাইটে আছেন, তাই একটি স্বাগতম বার্তা, অন-সাইট অফারের প্রম্পট বা জরিপ আমন্ত্রণ বিলম্বের সাথে তার মূল্য হারায়। যুক্ত হওয়ার জন্য পোলিং করা কোনো সুবিধা ছাড়াই লেটেন্সি বাড়ায়।
শুধুমাত্র পেলোডকে রেকর্ড তৈরি করতে দেবেন না। ইভেন্ট আইডি সংরক্ষণ করুন, তারপর অতিথিকে কোনো প্রক্রিয়ায় নিবন্ধিত করার আগে পরিচয় এবং সম্মতি নিশ্চিত করুন। একটি পর্যায়ক্রমিক API রিড আপনার রিসিভার ডাউন থাকার সময় মিস হয়ে যাওয়া যোগদানগুলি পুনরুদ্ধার করে।
POS বিক্রয়
Webhooks একই কারণে সেলসের জন্য উপযুক্ত, যার সাথে আরও বেশি ঝুঁকি জড়িত থাকে। একটি সমাপ্ত লেনদেন ভিজিটটি তাজা থাকতেই একটি রসিদ, পর্যালোচনা অনুরোধ, বা খরচ-ভিত্তিক সেগমেন্ট আপডেটকে ট্রিগার করতে পারে। আপনি যদি Purple Engage-এর জন্য Toast ইন্টিগ্রেশন-এর মতো কোনো টিল মূল্যায়ন করেন, তবে ঠিক কোনো লেনদেনের স্টেটগুলি ইভেন্ট নির্গমন করে, রিফান্ড এবং ভয়েডগুলি পৃথক ইভেন্ট নির্গমন করে কিনা এবং একটি আংশিক পরিশোধিত বিল কীভাবে প্রদর্শিত হয় তা নিশ্চিতভাবে পরীক্ষা করুন। ডেটাশীটের webhook শব্দের চেয়ে এই বিবরণগুলি অনেক বেশি গুরুত্বপূর্ণ।
এক্ষেত্রে ব্যর্থতার ধরনটি ব্যয়বহুল হতে পারে। ডুপ্লিকেট সেলস ইভেন্ট খরচ দ্বিগুণ গণনা করতে পারে, অ্যাট্রিবিউশন নষ্ট করতে পারে এবং ডুপ্লিকেট অফার ইস্যু করতে পারে। হ্যান্ডলারগুলোকে আইডেমপোটেন্ট করুন এবং চূড়ান্ত খরচের জন্য API রেকর্ডকে চূড়ান্ত নির্ভরযোগ্য হিসেবে বিবেচনা করুন।
বুকিং এবং রিজার্ভেশন
বুকিংয়ের জন্য উভয়ই প্রয়োজন, তবে API-এর দিকে বেশি গুরুত্ব দেওয়া হয়। একটি নতুন, পরিবর্তিত বা বাতিল হওয়া রিজার্ভেশনের জন্য একটি ওয়েবহুক আপনাকে দ্রুত প্রতিক্রিয়া জানাতে, নিশ্চিত করতে, মনে করিয়ে দিতে বা যাত্রার একটি ধাপ প্রকাশ করতে দেয়। কিন্তু বুকিং বারবার তার অবস্থা পরিবর্তন করে। অতিথির সংখ্যা পরিবর্তিত হয়, সময় পরিবর্তন হয়, ডিপোজিট জমা হয়।
একটি বুকিং ওয়েবহুক আপনাকে কেবল চেক করতে বলে। বুকিংটি বর্তমানে ঠিক কী অবস্থায় আছে, সে সম্পর্কে এটিই শেষ কথা হওয়া উচিত নয়।
গেস্ট-ফেসিং কিছু পাঠানোর আগে API-এর মাধ্যমে বর্তমান স্টেটটি পান। আপনি যদি একটি মিসড ক্যানসেলেশন ওয়েবহুকের পরে কোনও প্রাথমিক পেলোডের ওপর কাজ করেন, তবে আপনি একজন গেস্টকে এমন একটি টেবিল সম্পর্কে রিমাইন্ডার পাঠাবেন যা তার কাছে আর নেই।
হোটেল চেকআউট এবং স্টে
চেকআউটগুলি অবস্থান-পরবর্তী জরিপ এবং পর্যালোচনার অনুরোধ ট্রিগার করে, তাই একটি ওয়েবহুক আপনাকে সময়োপযোগী সূচনা প্রদান করে। অবস্থানের ইতিহাস, রুমের রাজস্ব এবং ফোলিও বিবরণ API রিডের অন্তর্ভুক্ত। এগুলি ঐতিহাসিক, পৃষ্ঠাঙ্কিত এবং চেকআউটের পরে সংশোধনের অধীন।
স্টে রেকর্ডের জন্য শুধুমাত্র ওয়েবহুকের ওপর নির্ভর করা একটি ক্লাসিক ভুল। রিসিভারের একটি আউটেজ হলে সেগমেন্টেশন থেকে পুরো স্টে অনুপস্থিত হয়ে যেতে পারে। এই ঘাটতি মেটাতে শিডিউল করা API রিকনসিলিয়েশন ব্যবহার করুন, এবং আপনি যখন কোনো প্রপার্টি অনবোর্ড করবেন তখন API-এর মাধ্যমে ব্যাকফিল করুন। প্রাসঙ্গিকভাবে, Purple Engage WiFi সাইন-ইন, POS রসিদ, বুকিং এবং হোটেল স্টে-কে একটি একক অতিথি রেকর্ডে একত্রিত করে, যা কেবল তখনই কাজ করে যখন প্রতিটি সোর্সের একটি ট্রিগার পাথ এবং একটি রিকভারি পাথ থাকে।
প্রোডাকশনে ভেঙে পড়ে না এমন একটি রিসিভার ডিজাইন করা
নির্ভরযোগ্যতা এমন কোনো ভেন্ডর ফিচার নয় যা আপনি কিনবেন। এটি প্রথম ভেন্যু লাইভ হওয়ার আগে নেওয়া আপনার সিদ্ধান্তের একটি সমষ্টি। নিখুঁতভাবে একবার নয়, অন্তত একবার ডেলিভারি নিশ্চিত করার জন্য ডিজাইন করুন, বাকি সবকিছু এমনিতেই অনুসরণ করবে।
দ্রুত স্বীকার করুন, পরে প্রসেস করুন
অনুরোধটি প্রমানীকৃত করুন, এটিকে স্থায়িভাবে কিউতে (queue) রাখুন, এবং তারপর সফলতা রিটার্ন করুন। শুধুমাত্র একটি 2xx রেসপন্স-কেই স্বীকৃতি হিসেবে গণ্য করুন, যেমনটি ওয়েবহুক ডেলিভারি গ্যারান্টি সম্পর্কিত Svix নির্দেশিকায় উল্লেখ করা হয়েছে। অনুরোধের হ্যান্ডলারের মধ্যে সেগমেন্টেশন, অফার ইস্যু করা, বা মেসেজ পাঠানোর কাজ করবেন না। ধীরগতির হ্যান্ডলার টাইমআউটের কারণ হয়, টাইমআউটের কারণে পুনরায় চেষ্টা করা হয়, এবং পুনরায় চেষ্টার ফলে আপনার ডুপ্লিকেট সংখ্যা বহুগুণ বেড়ে যায়।
একটি নথিভুক্ত সময়সূচীতে এক্সপোনেনশিয়াল ব্যাকঅফ এবং জিটারসহ প্রায় 41 ঘণ্টার মধ্যে মোট আটটি চেষ্টার জন্য 30 সেকেন্ড, 2 মিনিট, 15 মিনিট, 1 ঘণ্টা, 4 ঘণ্টা, 12 ঘণ্টা এবং 24 ঘণ্টার বিলম্ব ব্যবহার করা হয়, যা উপরে লিঙ্ক করা Svix নির্দেশিকা অনুযায়ী। এই সময়সীমার মধ্যেই আপনার ডিজাইনকে টিকে থাকতে হবে। এক দিন পরে কোনো পুনরায় চেষ্টা বা retry সফল হওয়া স্বাভাবিক, কোনো ব্যতিক্রম নয়।
ডুপ্লিকেটগুলোকে ক্ষতিহীন করে তুলুন
প্রোভাইডারের স্থিতিশীল ইভেন্ট আইডেন্টিফায়ার সংসংরক্ষণ করুন এবং এটি একটি idempotency key হিসাবে ব্যবহার করুন। আপনি যদি এটি আগেই দেখে থাকেন, তবে স্বীকার করুন এবং সাইড ইফেক্টটি এড়িয়ে যান। প্রক্রিয়া করতে ব্যর্থ হওয়া ডেলিভারিগুলি রিপ্লে সাপোর্ট সহ একটি dead-letter queue-তে চলে যায়, যাতে কোনও অপারেটর গেস্টদের অভিযোগের মাধ্যমে ঘাটতি খুঁজে পাওয়ার পরিবর্তে সেগুলি পরীক্ষা করতে এবং পুনরায় প্রক্রিয়া করতে পারেন।
ডাউনস্ট্রিম পরিকাঠামোতে ইভেন্ট স্ট্রিমিং করা টিমগুলির জন্য, Streamkap-এর এই no-code webhook Kafka integration গাইডটি ইনজেশন লেয়ার তৈরি না করেই webhook ইভেন্টগুলিকে Kafka-তে নিয়ে যাওয়ার জন্য একটি দরকারী রেফারেন্স। আপনি যা-ই বেছে নিন না কেন, কিউটি রিসিট এবং বিজনেস লজিকের মাঝখানে অবস্থান করে। এটি অত্যন্ত অপরিহার্য।
বিশ্বাস করার আগে যাচাই করুন
- র বডিতে HMAC সিগনেচার যাচাই করুন: প্রথমে পার্স করে পরে পুনরায় সিরিয়ালাইজ করলে আপনি বৈধ সিগনেচার ভেঙে ফেলবেন বা অবৈধ সিগনেচার গ্রহণ করবেন।
- টাইমস্ট্যাম্পের তাজা ভাব পরীক্ষা করুন: আজ পুনরায় প্লে করা একটি বৈধ পুরনো অনুরোধ অবশ্যই প্রত্যাখ্যান করতে হবে, যা ক্যাপচার করা পেলোড পুনরায় পাঠানোর বিরুদ্ধে আপনাকে রক্ষা করে।
- কনস্ট্যান্ট টাইমে তুলনা করুন: সাধারণ স্ট্রিং তুলনা টাইমিং সম্পর্কিত তথ্য ফাঁস করে দিতে পারে।
- উৎস অনুযায়ী অথরাইজ করুন: আপনার বুকিং প্রোভাইডারের একটি সিগনেচার যেন POS আকৃতির ইভেন্টগুলি লিখতে না পারে।
স্ট্যান্ডার্ডাইজেশন উন্নত হচ্ছে। Open Webhooks স্পেসিফিকেশন সাধারণ আইডেন্টিফায়ার, টাইমস্ট্যাম্প এবং HMAC-SHA256 সিগনেচারের উপর জোর দেয়, এবং RFC 9421 একটি স্ট্যান্ডার্ডাইজড HTTP মেসেজ সিগনেচার ফ্রেমওয়ার্ক প্রদান করে। সার্বজনীন গ্রহণের জন্য অপেক্ষা করবেন না। নিয়ন্ত্রণগুলি এখনই বাস্তবায়ন করুন।
শেষ মুহূর্তে সম্মতিক্রম বা Consent পুনরায় যাচাই করুন
গভর্নেন্স বা পরিচালনা নিশ্চিত করার জায়গাতেই ভেন্যু মার্কেটিং সাধারণ ইন্টিগ্রেশন পরামর্শ থেকে আলাদা হয়ে যায়। অ্যাপেন্ড-অনলি অডিট লগ রাখুন, ভেন্যুর টাইম জোন স্পষ্টভাবে পরিচালনা করুন, আঞ্চলিক প্রসেসিং প্রয়োজনীয়তা মেনে চলুন এবং যেকোনো বার্তা পাঠানো বা অফার দেওয়ার ঠিক আগে বর্তমান সম্মতি এবং যোগ্যতা পুনরায় পরীক্ষা করুন। মূল ইভেন্ট এবং ১২ ঘণ্টা পরের কোনো রিট্রাইয়ের মাঝে একজন অতিথি অপ্ট-আউট করতে পারেন। আপনার হ্যান্ডলারকে আগের পেলোডের পছন্দ নয়, পরবর্তী পছন্দকে সম্মান জানাতে হবে।
প্রকৃত পছন্দ কেন Webhook এর সাথে API এর সমন্বয়
প্রকৃত তুলনাটি webhook বনাম API নয়। এটি কেবল webhook বনাম webhook এর সাথে API। কেবল webhook ব্যবহার করলে তা প্রোডাকশনে ব্যর্থ হয়।
রিট্রাইয়ের ফলে ডুপ্লিকেট তৈরি হয়। ইভেন্টগুলি ভুল ক্রমানুসারে আসে, তাই একটি ক্যান্সেলেশন সেটি যে বুকিং বাতিল করে তার আগেই পৌঁছাতে পারে। একটি ক্ষণস্থায়ী আউটেজ এমন ঘাটতি তৈরি করে যা কেউ লক্ষ্য করে না যতক্ষণ না কোনো সেগমেন্ট নিয়মিত গেস্টদের সংখ্যা কম গণনা করে অথবা কোনো ক্যাম্পেইন এমন ভিজিটের ক্রেডিট দাবি করে যা এটি ঘটায়নি। লেটেন্সি বেঞ্চমার্ক এর কোনোটিই ক্যাপচার করতে পারে না।
ধারাবাহিকতার প্যাটার্ন যা কার্যকরভাবে কাজ করে
- যেকোনো প্রসেসিংয়ের আগে, রসিদে প্রোভাইডার ইভেন্ট ID সংরক্ষণ করুন।
- প্রতিটি হ্যান্ডলারকে আইডেমপোটেন্ট (idempotent) করুন, যাতে দ্বিতীয়বার ডেলিভারি হলে কোনো পরিবর্তন না হয়।
- যেকোনো পার্শ্বপ্রতিক্রিয়া, মেসেজ, অফার, সেগমেন্ট পরিবর্তন, বা রিডেম্পশনের আগে API-এর মাধ্যমে বর্তমান স্ট্যাটাস ফেচ (fetch) করুন।
- মিস হওয়া, পুনরায় ক্রমানুসারে সাজানো, বা সংশোধিত রেকর্ডগুলো খুঁজে বের করতে সোর্স স্ন্যাপশটের বিরুদ্ধে শডিউল করা রিকনসিলিয়েশন পরিচালনা করুন।
ওয়েবহুককে ডোরবেল এবং API-কে দরজায় কে এসেছে তা পরীক্ষা করা হিসেবে বিবেচনা করুন। এই ফ্রেমওয়ার্কটি WebinOne-এর বিল্ডারদের জন্য ওয়েবহুক বনাম API-এর সাথে মিলে যায়, যা বিল্ডার সাইডের ইমপ্লিমেন্টেশন পছন্দকে কভার করে। ভেন্যু টিমগুলির জন্য, পরিচালনগত ফলাফলই সবচেয়ে গুরুত্বপূর্ণ। অতিথি রেকর্ড, যেমন Purple Engage গেস্ট ডেটাতে বর্ণিত ইউনিফাইড ভিউ, কেবল তখনই বিশ্বস্ত হয় যখন এটিতে ডেটা সরবরাহকারী প্রতিটি উৎসের একটি রিকভারি পাথ থাকে, কেবল একটি ট্রিগার নয়।
ডিজাইন টেস্ট: আপনার সবচেয়ে ব্যস্ততম শনিবারে যদি আপনার রিসিভার এক ঘণ্টার জন্য অফলাইনে চলে যায়, তবে আপনি কি আগামীকাল প্রমাণ করতে পারবেন যে প্রতিটি WiFi জয়েন, সেল, বুকিং এবং চেকআউট বাস্তবে ঠিক একবার পুনরুদ্ধার করা হয়েছে? যদি না হয়, তবে আপনার এখনও একটি হাইব্রিড ডিজাইন নেই।
পুনর্মিলন বা reconciliation এড়িয়ে গেলে খরচের বোঝা বাড়তে থাকে। ডুপ্লিকেট জার্নি অতিথিদের বিরক্ত করে এবং অফারের বাজেট অপচয় করে। পুরনো সেগমেন্টেশনের কারণে গতকাল যারা ভেন্যুতে এসেছিলেন তাদের এমনভাবে টার্গেট করা হয় যেন তাদের আসা বন্ধ হয়ে গেছে। অ্যাট্রিবিউশন প্রকৃত প্রভাবকে বাড়িয়ে দেখায় কারণ কেনাকাটা দ্বিগুণ গণনা করা হয়েছে বা চেকআউট মিস হয়েছে। এগুলির কোনোটিই ড্যাশবোর্ডে ইন্টিগ্রেশন ত্রুটি হিসেবে দেখায় না। এগুলি এমন মার্জিটিং হিসেবে প্রকাশ পায় যার ওপর মানুষের বিশ্বাস ধীরে ধীরে উঠে যায়।
প্রথমবারই হাইব্রিড মডেল তৈরি করুন। এটি রিয়েল-টাইম ডেমোর চেয়ে কম চমকপ্রদ হতে পারে, তবে এটিই একটি মাল্টি-সাইট রোলআউটে টিকে থাকা ইন্টিগ্রেশন এবং আপনার টিমের ভরসা হারিয়ে ফেলা ইন্টিগ্রেশনের মধ্যে পার্থক্য তৈরি করে। কম-লেটেন্সি সিগন্যালের জন্য webhooks বেছে নিন, কর্তৃত্বপূর্ণ অবস্থা এবং রিকভারির জন্য APIs ব্যবহার করুন এবং বার্তা পাঠাতে বা অফার জারি করতে পারে এমন কিছুর জন্য এদের যেকোনো একটিকে একা ব্যবহার করা বন্ধ করুন।
আপনি যদি একটি মাল্টি-সাইট রোলআউটের পরিকল্পনা করেন এবং সাইন করা ওয়েবহুক, একটি পাবলিক API এবং পাঠানোর আগে আবার যাচাই করা সম্মতির মাধ্যমে WiFi, POS, বুকিং এবং স্টে (stay) তথ্যগুলো একটি একক অতিথি রেকর্ডে সমন্বিত করতে চান, তবে Purple Engage ঘুরে দেখুন এবং উপরের হাইব্রিড চেকলিস্টের সাথে এর ইন্টিগ্রেশনগুলো পর্যালোচনা করুন। আপনার সবচেয়ে জটিল ইভেন্টটি - যে POS বিক্রি বা চেকআউটটি আপনি কোনোভাবেই ডুপ্লিকেট করতে চান না - সেটি আনুন এবং কোনো আউটেজের পর সিস্টেমের ডিজাইন তা পুনরুদ্ধার করতে পারে কিনা পরীক্ষা করুন।