Fleet Engine রিয়েল-টাইম ইভেন্ট

গ্রাউন্ডে অপারেট করা ফ্লিট থেকে পাওয়া প্রায় রিয়েল-টাইম সিগন্যাল বিভিন্ন উপায়ে ব্যবসার জন্য উপযোগী। যেমন, ব্যবসাগুলি এগুলি ব্যবহার করতে পারে:

  • তাদের ফ্লিটের পারফর্ম্যান্স মনিটর করা এবং সম্ভাব্য সমস্যা আগে থেকেই শনাক্ত করা
  • সঠিক ETA এবং ট্র্যাকিং তথ্য প্রদান করে গ্রাহক পরিষেবা উন্নত করুন
  • অদক্ষতা শনাক্ত করে এবং তার সমাধান করে খরচ কমানো
  • ড্রাইভারের আচরণ মনিটর করে এবং সম্ভাব্য বিপদ শনাক্ত করে নিরাপত্তা উন্নত করুন
  • দক্ষতা বাড়াতে ড্রাইভারের রুট ও শিডিউল অপ্টিমাইজ করুন
  • গাড়ির লোকেশন ও পরিষেবার সময় ট্র্যাক করে রেগুলেশন মেনে চলুন

এই ডকুমেন্ট থেকে জানা যায় যে ডেভেলপাররা কীভাবে Google Maps Platform-এর "মোবিলিটি পরিষেবা" ("লাস্ট মাইল ফ্লিট সলিউশন" (LMFS) বা "অন-ডিমান্ড রাইড ও ডেলিভারি সলিউশন" (ODRD) থেকে পাওয়া সিগন্যালকে অ্যাকশনযোগ্য কাস্টম ইভেন্টে পরিণত করতে পারেন। GitHub-এ উপলভ্য ফ্লিট ইভেন্ট রেফারেন্স সলিউশন-এর মূল ধারণা ও ডিজাইন সংক্রান্ত সিদ্ধান্তও কভার করা হয়েছে।

এই ডকুমেন্টটি এর সাথে প্রাসঙ্গিক:

  • Google Maps Platform-এর "Mobility পরিষেবা" এবং এর অন্যতম মূল কম্পোনেন্ট "Fleet Engine" সম্পর্কে পরিচিত আর্কিটেক্ট। "মোবিলিটি পরিষেবা" যারা নতুন ব্যবহার করছেন, তাদের জন্য আমরা সাজেস্ট করি যে আপনার প্রয়োজন অনুযায়ী লাস্ট মাইল ফ্লিট সলিউশন এবং/অথবা অন-ডিমান্ড রাইড ও ডেলিভারি সলিউশন সম্পর্কে জেনে নিন।
  • Google Cloud সম্পর্কে জানেন এমন আর্কিটেক্ট। যারা Google Cloud-এ নতুন, তাদের জন্য Google Cloud-এ স্ট্রিমিং ডেটা পাইপলাইন তৈরি করা হল একটি সাজেস্ট করা প্রি-রিড।
  • আপনি যদি অন্য এনভায়রনমেন্ট বা সফ্টওয়্যার স্ট্যাক টার্গেট করেন, তাহলে Fleet Engine-এর ইন্টিগ্রেশন পয়েন্ট এবং মূল বিবেচ্য বিষয়গুলি বোঝার উপর ফোকাস করুন, যা এখনও প্রযোজ্য হওয়া উচিত।
  • ফ্লিট থেকে কীভাবে ইভেন্ট তৈরি ও ব্যবহার করা যায় তা এক্সপ্লোর করার ব্যাপারে যাদের সাধারণ আগ্রহ আছে।

এই ডকুমেন্ট পড়া শেষ করার পরে, আপনি স্ট্রিমিং সিস্টেমের মূল উপাদান ও বিবেচ্য বিষয়গুলি সম্পর্কে প্রাথমিক ধারণা পাবেন। এর পাশাপাশি, Google Maps Platform ও Google Cloud-এর বিল্ডিং ব্লক সম্পর্কেও জানতে পারবেন, যেগুলি Fleet Events Reference Solution তৈরি করে।

Fleet Events Reference Solution-এর ওভারভিউ

ফ্লিট ইভেন্ট রেফারেন্স সলিউশন হল একটি ওপেন সোর্স সলিউশন যা মোবিলিটি গ্রাহক এবং পার্টনারদের ফ্লিট ইঞ্জিন এবং Google Cloud কম্পোনেন্টের উপরে গুরুত্বপূর্ণ ইভেন্ট তৈরি করতে সক্ষম করে। আজ, রেফারেন্স সলিউশন গ্রাহকদের সহায়তা করে লাস্ট মাইল ফ্লিট সলিউশন ব্যবহার করে অন-ডিমান্ড রাইড এবং ডেলিভারির জন্য সহায়তা সহ অনুসরণ করতে.

টাস্ক বা ট্রিপের সাথে যুক্ত নির্দিষ্ট ডেটার পরিবর্তনের উপর ভিত্তি করে সমাধানটি অটোমেটিক ইভেন্ট তৈরি করে। আপনি এইসব ইভেন্ট ব্যবহার করে স্টেকহোল্ডারদের বিজ্ঞপ্তি পাঠাতে পারেন যেমন নিম্নলিখিত বিজ্ঞপ্তি বা আপনার ফ্লিটের জন্য অন্যান্য অ্যাকশন ট্রিগার করতে পারেন।

  • টাস্কের জন্য পৌঁছানোর ETA পরিবর্তন
  • টাস্ক আসার জন্য আপেক্ষিক ETA পরিবর্তন
  • টাস্কের সময় হতে বাকি আছে
  • টাস্কের লোকেশনে পৌঁছাতে বাকি দূরত্ব
  • TaskOutcome স্ট্যাটাস পরিবর্তন

আপনার ব্যবসার প্রয়োজন অনুযায়ী রেফারেন্স সলিউশনের প্রতিটি কম্পোনেন্ট কাস্টমাইজ করা যেতে পারে।

লজিক্যাল বিল্ডিং ব্লক

ডায়াগ্রাম : নিম্নলিখিত ডায়াগ্রামটি হাই লেভেল বিল্ডিং ব্লক দেখায় যা ফ্লিট ইভেন্ট রেফারেন্স সলিউশন তৈরি করে

ফ্লিট ইভেন্টের ওভারভিউ এবং লজিক্যাল বিল্ডিং ব্লক

রেফারেন্স সমাধানে নিম্নলিখিত কম্পোনেন্ট থাকে:

  • ইভেন্ট সোর্স: আসল ইভেন্ট স্ট্রিম কোথা থেকে আসছে। "লাস্ট মাইল ফ্লিট সলিউশন" বা "অন-ডিমান্ড রাইড ও ডেলিভারি সলিউশন" উভয়ই Cloud Logging-এর সাথে ইন্টিগ্রেট করা আছে যা ফ্লিট ইঞ্জিন RPC কল লগগুলিকে ডেভেলপারদের জন্য উপলভ্য ইভেন্ট স্ট্রিমে পরিণত করতে সাহায্য করে। এটি হল ব্যবহার করার জন্য মূল সোর্স।
  • প্রসেস করা হচ্ছে: এই ব্লকের মধ্যে র RPC কল লগ স্টেট পরিবর্তন ইভেন্টে কনভার্ট করা হয় যা লগ ইভেন্টের স্ট্রিমের উপর গণনা করে। এই ধরনের পরিবর্তন শনাক্ত করতে, এই কম্পোনেন্টের জন্য একটি স্টেট স্টোর প্রয়োজন যাতে নতুন ইনকামিং ইভেন্টগুলি পরিবর্তনের শনাক্তকরণের জন্য আগের ইভেন্টগুলির সাথে তুলনা করা যায়। ইভেন্টে সবসময় আপনার আগ্রহের সব তথ্য নাও থাকতে পারে। এই ধরনের ক্ষেত্রে, এই ব্লকটি প্রয়োজন অনুযায়ী ব্যাকএন্ডে লুক আপ কল করতে পারে।
    • স্টেট স্টোর: কিছু প্রসেসিং ফ্রেমওয়ার্ক ইন্টারমিডিয়েট ডেটা প্রদান করে যা নিজের থেকে পারসিস্টেন্ট হয়। কিন্তু তা না হলে, আপনার নিজের স্টোর স্টেট করার জন্য, যেহেতু এগুলি কোনও গাড়ি এবং ইভেন্টের ধরনের জন্য অনন্য হওয়া উচিত, তাই K-V ধরনের ডেটা পারসিস্টেন্স পরিষেবা একটি ভাল ফিট।
  • সিঙ্ক (কাস্টম ইভেন্ট): শনাক্ত করা স্ট্যাটাসের পরিবর্তন এমন যেকোনও অ্যাপ্লিকেশন বা পরিষেবার জন্য উপলভ্য করা উচিত যা এর থেকে উপকৃত হতে পারে। তাই, ডাউনস্ট্রিম কনজাম্পশনের জন্য ইভেন্ট ডেলিভারি সিস্টেমে এই কাস্টম ইভেন্ট প্রকাশ করা একটি স্বাভাবিক পছন্দ।
  • ডাউনস্ট্রিম পরিষেবা: কোড যা জেনারেট করা ইভেন্ট ব্যবহার করে এবং আপনার ব্যবহারের ক্ষেত্রে অনন্য অ্যাকশন নেয়।

পরিষেবা বেছে নেওয়া

"লাস্ট মাইল ফ্লিট সলিউশন" বা "অন-ডিমান্ড রাইড ও ডেলিভারি সলিউশন" (২০২৩-এর ৩য় কোয়ার্টারের শেষের দিকে আসছে)-এর জন্য রেফারেন্স সলিউশন প্রয়োগ করার ক্ষেত্রে, "সোর্স" ও "সিঙ্ক"-এর জন্য প্রযুক্তি বেছে নেওয়া সহজ। অন্যদিকে, "প্রসেসিং" বিকল্পে অনেক ধরনের বিকল্প রয়েছে। রেফারেন্স সলিউশন নিম্নলিখিত Google পরিষেবা বেছে নিয়েছে।

ডায়াগ্রাম : নিম্নলিখিত ডায়াগ্রামটি Google Cloud পরিষেবা দেখায় যা রেফারেন্স সমাধান প্রয়োগ করে

Fleet Events রেফারেন্স সলিউশন বিল্ডিং ব্লক

ক্লাউড প্রোজেক্ট লেআউট

আমরা সাজেস্ট করি যে আপনি ডিফল্ট হিসেবে মাল্টি-প্রোজেক্ট ডিপ্লয়মেন্ট ব্যবহার করুন। এটি করা হয় যাতে Google Maps Platform এবং Google Cloud-এর ব্যবহার স্পষ্টভাবে আলাদা করা যায় এবং আপনার পছন্দের বিলিং ব্যবস্থার সাথে যুক্ত করা যায়।

ইভেন্ট সোর্স

"লাস্ট মাইল ফ্লিট সলিউশন" এবং "অন-ডিমান্ড রাইড ও ডেলিভারি সলিউশন" API অনুরোধ ও রেসপন্স পে-লোড Cloud Logging-এ লেখে। Cloud Logging এক বা একাধিক পছন্দের পরিষেবায় লগ ডেলিভার করে। Cloud Pub/Sub-এ রাউটিং করা এখানে একটি নিখুঁত পছন্দ এবং কোডিং ছাড়াই লগগুলিকে একটি ইভেন্ট স্ট্রিমে রূপান্তর করার অনুমতি দেয়।

সিঙ্ক

Google Cloud-এ, Cloud Pub/Sub হল প্রায় রিয়েল-টাইম মেসেজ ডেলিভারি সিস্টেমের বিকল্প। সোর্স থেকে ইভেন্ট যেভাবে Pub/Sub-এ ডেলিভার করা হয়, ঠিক সেভাবেই কাস্টম ইভেন্টও ডাউনস্ট্রিম ব্যবহারের জন্য Pub/Sub-এ প্রকাশ করা হয়।

প্রসেস করা হচ্ছে

ইভেন্ট প্রসেস করার ক্ষেত্রে নিম্নলিখিত কম্পোনেন্টগুলি ভূমিকা পালন করে। অন্যান্য বিল্ডিং ব্লকের মতো, প্রসেসিং কম্পোনেন্টগুলি সম্পূর্ণ সার্ভারলেস এবং আপ ও ডাউন উভয় ক্ষেত্রেই ভালভাবে স্কেল করে।

  • প্রাথমিক রিলিজের জন্য কম্পিউট প্ল্যাটফর্ম হিসেবে Cloud Functions (*)
    • সার্ভারলেস, খরচ ম্যানেজ করার জন্য স্কেলিং কন্ট্রোলের মাধ্যমে স্কেল আপ ও ডাউন করে
    • প্রোগ্রামিং ল্যাঙ্গুয়েজ হিসেবে Java ব্যবহার করা হয় কারণ Fleet Engine সম্পর্কিত API-এর জন্য ক্লায়েন্ট লাইব্রেরি উপলভ্য থাকে, যা বাস্তবায়ন করা সহজ করে তোলে
  • স্টেট স্টোর হিসেবে Cloud Firestore
    • সার্ভারলেস কী-ভ্যালু স্টোর
  • Cloud Pub/Sub আপস্ট্রিম ও ডাউনস্ট্রিম কম্পোনেন্টের সাথে ইন্টিগ্রেশন পয়েন্ট হিসেবে
    • লুজলি কাপল্ড নিয়ার-রিয়েল টাইম ইন্টিগ্রেশন

ফাংশনগুলি ডিফল্ট সেটিংসের সাথে যেমন আছে তেমন ব্যবহার করা যেতে পারে, তবে সেগুলি আবার কনফিগারও করা যেতে পারে। কনফিগারেশন প্যারামিটার ডিপ্লয়মেন্ট স্ক্রিপ্টের মাধ্যমে সেট করা হয় এবং সংশ্লিষ্ট Terraform মডিউল README-তে বিস্তারিতভাবে ডকুমেন্ট করা হয়।

*মনে রাখবেন: এই রেফারেন্স সলিউশন বিকল্প ইমপ্লিমেন্টেশন রিলিজ করার পরিকল্পনা করে যা বিভিন্ন প্রয়োজনীয়তা পূরণ করতে সাহায্য করতে পারে।

ডিপ্লয়মেন্ট

রেফারেন্স সলিউশন ডিপ্লয়মেন্ট প্রসেস রিপিটেবল, কাস্টমাইজ করার উপযুক্ত, সোর্স কোড কন্ট্রোল করার উপযুক্ত ও সুরক্ষিত করতে, অটোমেশন টুল হিসেবে Terraform বেছে নেওয়া হয়েছে। Terraform হল একটি ব্যাপকভাবে গৃহীত IaC (ইনফ্রাস্ট্রাকচার অ্যাজ কোড) টুল যা Google Cloud-এর জন্য সমৃদ্ধ সহায়তা প্রদান করে।

Terraform মডিউল

একটি বড় মনোলিথিক রেফারেন্স সলিউশন ডিপ্লয়মেন্ট মডিউল তৈরি করার পরিবর্তে, অটোমেশনের পুনর্ব্যবহারযোগ্য ব্লকগুলি Terraform মডিউল হিসেবে প্রয়োগ করা হয় যা স্বাধীনভাবে ব্যবহার করা যেতে পারে। মডিউলগুলি কনফিগারযোগ্য ভেরিয়েবলের একটি বিস্তৃত পরিসর প্রদান করে, যার বেশিরভাগেরই ডিফল্ট মান থাকে যাতে আপনি দ্রুত শুরু করতে পারেন তবে আপনার প্রয়োজন এবং পছন্দের উপর ভিত্তি করে কাস্টমাইজ করার নমনীয়তাও রয়েছে।

রেফারেন্স সমাধানে অন্তর্ভুক্ত মডিউল:

  • Fleet Engine লগিং কনফিগারেশন: Fleet Engine-এর সাথে ব্যবহার করার জন্য Cloud Logging সম্পর্কিত কনফিগারেশন অটোমেট করুন। রেফারেন্স সলিউশনে, এটি নির্দিষ্ট Pub/Sub টপিকে Fleet Engine সম্পর্কিত লগ রুট করতে ব্যবহার করা হয়।
  • Fleet Events ক্লাউড ফাংশন ডেপ্লয়মেন্ট: স্যাম্পেল ফাংশন কোড ডেপ্লয়মেন্ট অন্তর্ভুক্ত করে এবং সুরক্ষিত ক্রস-প্রোজেক্ট ইন্টিগ্রেশনের জন্য প্রয়োজনীয় অনুমতি সেটিংসের অটোমেশনও ম্যানেজ করে।
  • সম্পূর্ণ রেফারেন্স সলিউশন ডেপ্লয়মেন্ট: আগের দুটি মডিউলকে কল করে এবং সম্পূর্ণ সলিউশনকে র‍্যাপ করে।

নিরাপত্তা

Google Cloud-এর নিরাপত্তা সংক্রান্ত পেশাদার পদ্ধতি যেমন, পরিষেবা অ্যাকাউন্ট ছদ্মবেশের সাথে সাথে ন্যূনতম বিশেষাধিকার নীতি প্রয়োগ করার জন্য IAM গ্রহণ করা হয়। নিরাপত্তার উপর আপনাকে আরও নিয়ন্ত্রণ দিতে Google Cloud কী অফার করে তা আরও ভালোভাবে বুঝতে নিম্নলিখিত নিবন্ধগুলি দেখুন।

পরবর্তী অ্যাকশন

আপনি এখন ফ্লিট ইভেন্ট রেফারেন্স সলিউশন অ্যাক্সেস ও আরও এক্সপ্লোর করার জন্য প্রস্তুত। শুরু করতে GitHub-এ যান।

পরিশিষ্ট

আপনার প্রয়োজনীয়তা সংগ্রহ করুন

প্রসেস শুরু করার আগেই আপনার প্রয়োজনীয়তাগুলি সংগ্রহ করে নিলে ভালো হয়।

প্রথমে, আপনি কেন প্রায়-রিয়েল-টাইম ইভেন্ট ব্যবহার করতে আগ্রহী বা কেন এটি ব্যবহার করা প্রয়োজন সেই সংক্রান্ত বিবরণ ক্যাপচার করুন। আপনার প্রয়োজনীয়তা আরও স্পষ্ট করে বুঝতে এখানে কিছু প্রশ্ন দেওয়া হল।

  • ইভেন্ট স্ট্রিম কার্যকর করার জন্য কী কী তথ্য প্রয়োজন?
    • Google পরিষেবায় ক্যাপচার করা বা তৈরি করা ডেটা থেকে কি ফলাফল পাওয়া যেতে পারে? অথবা, ইন্টিগ্রেট করা এক্সটার্নাল সিস্টেমের সাথে ডেটা এনরিচমেন্ট প্রয়োজন? যদি তাই হয়, তাহলে সেই সিস্টেমগুলি কী এবং তারা কী ইন্টিগ্রেশন ইন্টারফেস অফার করে?
    • ব্যবসা হিসেবে আপনি কোন মেট্রিক পরিমাপ করতে চান? এগুলি কীভাবে সংজ্ঞায়িত করা হয়?
    • ইভেন্ট জুড়ে মেট্রিক গণনা করতে হলে, কোন ধরনের অ্যাগ্রিগেশন প্রয়োজন হবে? লজিক্যাল ধাপগুলি সাজানোর চেষ্টা করুন। (যেমন, সম্পদের সীমাবদ্ধতার অধীনে পারফরম্যান্স গণনা করতে পিক আওয়ারের সময় ফ্লিটের একটি সাবসেট জুড়ে SLO-এর বিপরীতে ETA/ATA তুলনা করুন।)
  • আপনি কেন ব্যাচের পরিবর্তে ইভেন্ট-ভিত্তিক মডেলে আগ্রহী? এটি কি কম লেটেন্সি (টাইম-টু-অ্যাকশন) বা লুজলি কাপল্ড ইন্টিগ্রেশনের (অ্যাজিলিটি) জন্য?
    • কম লেটেন্সির জন্য "কম" হিসেবে উল্লেখ করুন। মিনিট? সেকেন্ড? সাব-সেকেন্ড? আর লেটেন্সি কত?
  • আপনি কি টিম হিসেবে টেকনোলজি স্ট্যাক ও সংশ্লিষ্ট দক্ষতায় আগে থেকেই বিনিয়োগ করেছেন? যদি থাকে, তাহলে সেটি কী এবং এটি কী কী ইন্টিগ্রেশন পয়েন্ট প্রদান করে?
    • এমন কোনও প্রয়োজনীয়তা আছে যা আপনার বর্তমান সিস্টেম পূরণ করতে পারছে না অথবা আপনার ফ্লিট থেকে আসা ইভেন্ট প্রসেস করার সময় সমস্যার সম্মুখীন হচ্ছে?

ডিজাইন সংক্রান্ত নীতি

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

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

স্ট্রিমিং কনসেপ্ট

আপনি যদি ইভেন্ট-ভিত্তিক বা স্ট্রিমিংয়ের ক্ষেত্রে তুলনামূলকভাবে নতুন হন, তাহলে কিছু মূল ধারণা সম্পর্কে সচেতন থাকা উচিত, যার মধ্যে কিছু ব্যাচ প্রসেসিং থেকে খুব আলাদা হতে পারে।

  • স্কেল : ব্যাচ প্রসেসিংয়ের ক্ষেত্রে, প্রসেস করার জন্য ডেটার পরিমাণ সম্পর্কে আপনার সাধারণত একটি ভালো ধারণা থাকে, কিন্তু স্ট্রিমিংয়ের ক্ষেত্রে তা থাকে না। কোনও শহরে ট্রাফিক জ্যামের কারণে নির্দিষ্ট এলাকা থেকে হঠাৎ করে অনেক ইভেন্ট জেনারেট হতে পারে এবং আপনাকে এখনও এটি প্রসেস করতে হবে।
  • উইন্ডো করা : একটি একটি করে ইভেন্ট প্রসেস করার পরিবর্তে, প্রায়ই এমন হয় যে আপনি টাইমলাইন জুড়ে ইভেন্টগুলিকে ছোট "উইন্ডো"তে গ্রুপ করতে চান, যা গণনার জন্য একটি ইউনিট হিসেবে কাজ করে। বিভিন্ন উইন্ডোইং স্ট্র্যাটেজি আছে, যেমন "ফিক্সড উইন্ডো (যেমন, প্রতিটি ক্যালেন্ডার দিন)", "স্লাইডিং উইন্ডো (শেষ ৫ মিনিট)", "সেশন উইন্ডো (এই ট্রিপ চলাকালীন)", যেগুলি থেকে আপনাকে বেছে নিতে হবে। উইন্ডো যত দীর্ঘ হবে, ফলাফল তৈরি করতে তত বেশি দেরি হবে। আপনার প্রয়োজন অনুযায়ী সঠিক মডেল ও কনফিগারেশন বেছে নিন।
  • ট্রিগার করা : এমন কিছু পরিস্থিতি আছে যেখানে তুলনামূলকভাবে দীর্ঘ উইন্ডো রাখা ছাড়া আপনার কাছে আর কোনও বিকল্প নেই। তবুও, আপনি ইভেন্ট তৈরি করার জন্য উইন্ডোর একেবারে শেষ পর্যন্ত অপেক্ষা করতে চান না, বরং এর পরিবর্তে, মাঝামাঝি সময়ে অন্তর্বর্তী ফলাফল প্রকাশ করতে চান। এই ধারণাটি এমন ব্যবহারের ক্ষেত্রে প্রয়োগ করা যেতে পারে যেখানে প্রথমে দ্রুত ফলাফল প্রদান করা এবং পরে সেগুলি সংশোধন করা মূল্যবান। Imagine emitting intermediate status at 25%, 50%, 75% completion of a delivery.
  • ক্রম : ইভেন্টগুলি যে ক্রমে তৈরি করা হয়েছে সেই ক্রমেই সিস্টেমে পৌঁছায় না। বিশেষ করে মোবাইল নেটওয়ার্কের মাধ্যমে যোগাযোগের ক্ষেত্রে যেখানে দেরি হয় এবং জটিল রাউটিং পাথ থাকে। আপনাকে "ইভেন্টের সময়" (ইভেন্টটি আসলে কখন ঘটেছে) এবং "প্রসেস করার সময়" (ইভেন্টটি কখন সিস্টেমে পৌঁছেছে) এর মধ্যে পার্থক্য সম্পর্কে সচেতন হতে হবে এবং সেই অনুযায়ী ইভেন্টগুলি ম্যানেজ করতে হবে। সাধারণত, আপনি "ইভেন্টের সময়" অনুযায়ী ইভেন্ট প্রসেস করতে চান।
  • মেসেজ ডেলিভারি - অন্তত-একবার বনাম ঠিক-একবার: বিভিন্ন ইভেন্ট প্ল্যাটফর্মের এগুলির উপর আলাদা আলাদা সাপোর্ট রয়েছে। আপনার ব্যবহারের উপর নির্ভর করে, আপনাকে আবার চেষ্টা করা বা ডিডুপ্লিকেশন স্ট্র্যাটেজি বিবেচনা করতে হবে।
  • সম্পূর্ণতা : ক্রম পরিবর্তনের মতোই, মেসেজ হারিয়ে যাওয়ার সম্ভাবনা থাকে। ডিভাইসের ব্যাটারি শেষ হয়ে যাওয়ার কারণে অ্যাপ্লিকেশন ও ডিভাইস বন্ধ হয়ে যাওয়া, ফোনের অনিচ্ছাকৃত ক্ষতি, টানেলে থাকার সময় কানেক্টিভিটি হারিয়ে যাওয়া অথবা গ্রহণযোগ্য উইন্ডোর বাইরে মেসেজ পাওয়ার কারণে এটি হতে পারে। অসম্পূর্ণতা আপনার ফলাফলের উপর কীভাবে প্রভাব ফেলবে?

এটি সম্পূর্ণ তালিকা নয়, তবে একটি ভূমিকা। এখানে কিছু অত্যন্ত সুপারিশ করা রিড রয়েছে যা আপনাকে প্রতিটির বিষয়ে আপনার বোঝাপড়াকে আরও গভীর করতে সাহায্য করতে পারে।

অবদানকারী

Google এই ডকুমেন্টটি রক্ষণাবেক্ষণ করে। নিম্নলিখিত কন্ট্রিবিউটররা এটি লিখেছেন।

প্রধান লেখক: