Kafka কী এবং আধুনিক সিস্টেমে এটি কীভাবে ব্যবহৃত হয়?

Kafka সহজ ভাষায়

Apache Kafka হলো একটি বিতরণকৃত ইভেন্ট স্ট্রিমিং প্ল্যাটফর্ম। সহজভাবে বললে, এটি একটি শেয়ার করা, স্থায়ী “নলিকা” যা অনেক সিস্টেমকে ঘটে যাওয়া বিষয়গুলি প্রকাশ করতে দেয় এবং অন্য সিস্টেমগুলো সেই বিষয়গুলো দ্রুত, স্কেলে এবং ধারাবাহিকভাবে পড়তে পারে।

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

কিছু টার্ম যা আপনি দেখবেন

• ইভেন্ট / মেসেজ: কোন ঘটনার রেকর্ড (উদাহরণ: “OrderPlaced” বা “PaymentFailed”)। Kafka ব্যবহারকারীরা প্রায়ই “মেসেজ” বলেন, কিন্তু “ইভেন্ট” বললে বোঝায় যে এটি বাস্তব-জগতের একটি পরিবর্তন উপস্থাপন করে।
• স্ট্রিম: সময়ের সঙ্গে ইভেন্টগুলোর একটি ধারাবাহিক প্রবাহ।
• লগ: Kafka ইভেন্টগুলোকে append-only লগ হিসেবে সংগঠিত করে—নতুন ইভেন্ট শেষে যোগ করা হয়, এবং রিডাররা তাদের গতি নিজের মতো চালায়।

এই গাইড কার জন্য (এবং আপনি কী শিখবেন)

এই গাইডটি প্রোডাক্ট-মাইন্ডেড ইঞ্জিনিয়ার, ডাটা পেশাজীবী এবং প্রযুক্তিগত নেতা যারা Kafka‑এর একটি ব্যবহারিক মানসিক মডেল চান তাদের জন্য।

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

কোর কনসেপ্ট: প্রোডিউসার, কনসিউমার, টপিক, ব্রোকার

Kafka‑কে বুঝতে সহজ হলে তা হলো একটি শেয়ার করা ইভেন্ট লগ: অ্যাপগুলো এতে ইভেন্ট লিখে, আর অন্য অ্যাপগুলো পরে সেগুলো পড়ে—প্রায়শই রিয়েল‑টাইমে, কখনো কখনো ঘন্টার বা দিনের পরেও।

প্রোডিউসার এবং কনসিউমার

প্রোডিউসার হলো লেখক। এক প্রোডিউসার “order placed”, “payment confirmed”, বা “temperature reading” মতো ইভেন্ট পাবলিশ করতে পারে। প্রোডিউসাররা ইভেন্টগুলো নির্দিষ্ট অ্যাপে পাঠায় না—তারা Kafka-তে পাঠায়।

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

টপিক: ইভেন্টগুলোকে অ্যাক্সেসিং করা

Kafka‑র ইভেন্টগুলো টপিক এ গ্রুপ করা হয়—প্রায়ই নামকৃত ক্যাটেগরি। উদাহরণ:

• orders — অর্ডার সম্পর্কিত ইভেন্ট
• payments — পেমেন্ট ইভেন্ট
• inventory — স্টক পরিবর্তন

একটি টপিক ঐ ধরনের ইভেন্টের “সোর্স অফ ট্রুথ” স্ট্রিমে পরিণত হয়, যা একাধিক টিমকে একই ডেটা পুনরায় ব্যবহার করতে সহজ করে তোলে—এক-অফ ইন্টিগ্রেশন না বানিয়েই।

ব্রোকার এবং ক্লাস্টার

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

কনসিউমার গ্রুপ: কাজ স্কেল করা ডুপ্লিকেশন ছাড়া

কনসিউমাররা প্রায়ই একটি কনসিউমার গ্রুপ এ চলে। Kafka গ্রুপের মধ্যে পড়া কাজ ভাগ করে দেয়, তাই আপনি প্রসেসিং স্কেল আউট করতে পারেন—প্রতিটি ইনস্ট্যান্স একই কাজ করে না।

কিভাবে টপিক ও পার্টিশন Kafka‑কে স্কেল করে

Kafka স্কেল করে কাজকে ভাগ করে নিয়ে: প্রথমে বিষয়ভিত্তিক স্ট্রিমগুলিকে টপিক এ বিভাজন করে এবং প্রতিটি টপিককে ছোট, স্বাধীন ফালি হিসেবে পার্টিশন এ ভাগ করে।

পার্টিশন = প্যারালালিজম ও থ্রুপুট

একটি টপিক যার একটি পার্টিশন আছে সেটি একই গ্রুপের এক কনসিউমার দ্বারা একবারে পড়া যাবে। পার্টিশন বাড়ালে আপনি আরও কনসিউমার যোগ করে ইভেন্টসমূহ সমান্তরালে প্রক্রিয়াকরণ করতে পারেন। এভাবেই Kafka উচ্চ-ভলিউম ইভেন্ট স্ট্রিমিং এবং রিয়েল‑টাইম ডাটা পাইপলাইন সমর্থন করে।

পার্টিশন ব্রোকার জুড়ে লোড ছড়িয়ে দিতে সাহায্য করে—একটি টপিকের সব রাইট/রিড এক মেশিনে না পড়ে, বিভিন্ন ব্রোকার আলাদা পার্টিশন হোস্ট করে ট্রাফিক ভাগ করে নেয়।

অর্ডারিং: Kafka কি গ্যারান্টি দেয় (এবং দেয় না)

Kafka একটি একক পার্টিশনের ভেতরে অর্ডারিং গ্যারান্টি দেয়। যদি ইভেন্ট A, B, C একই পার্টিশনে সেই ক্রমে লেখা হয়, কনসিউমাররা তাদের A → B → C ক্রমে পড়বে।

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

কী নির্ধারণ করে ইভেন্ট কোথায় যাবে

প্রোডিউসাররা ইভেন্ট পাঠানোর সময় একটি কী (যেমন order_id) দিতে পারে। Kafka কী ব্যবহার করে সংশ্লিষ্ট ইভেন্টগুলোকে একই পার্টিশনে ধারাবাহিকভাবে রুট করে। এতে ঐ কী‑এর জন্য ভবিষ্যদ্বাণীমূলক অর্ডারিং পাওয়া যায়, তবু পুরো টপিক বহু পার্টিশনে স্কেল করতে পারে।

রেপ্লিকা ডেটাকে উপলব্ধ রাখে

প্রতিটি পার্টিশন অন্যান্য ব্রোকারে রিপ্লিকেট করা যায়। যদি একটি ব্রোকার ব্যর্থ হয়, অন্য রিপ্লিকা থাকার কারণে সেটি দায়িত্ব নেবে। রেপ্লিকেশনই Kafka‑কে মিশন‑ক্রিটিক্যাল পাব‑সাব মেসেজিং ও ইভেন্ট‑ড্রিভেন সিস্টেমে বিশ্বাসযোগ্য করে তোলে: এটি উপলব্ধতা বাড়ায় এবং ফল্ট টলারেন্স দেয়।

স্টোরেজ, রিটেনশন, এবং ইভেন্ট রি‑প্লে

Apache Kafka‑র একটি মূল ধারণা হলো ইভেন্টগুলো কেবল হ্যান্ড‑অফ করা হয় না—তারা ডিস্কে লেখা হয় একটি সাজানো লগে, তাই কনসিউমাররা এখন বা পরে সেগুলো পড়তে পারে। এ কারণে Kafka কেবল ডেটা সরানোর জন্য নয়, ঘটনার স্থায়ী ইতিহাস রাখার জন্যও শক্তিশালী।

ইভেন্টগুলো ট্রানজিটিভ নয়, পার্সিস্টেড

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

রিটেনশন: Kafka কতক্ষণ ডেটা রাখে

Kafka টপিক অনুযায়ী ইভেন্ট রাখে:

• সময়ভিত্তিক রিটেনশন: নির্দিষ্ট সময় (উদাহরণ: ৭ দিন) ধরে রাখুন।
• সাইজভিত্তিক রিটেনশন: লগ নির্দিষ্ট সাইজ পৌঁছানো পর্যন্ত রাখুন, তারপর পুরনো ডেটা মুছে দিন।

প্রতি টপিকে রিটেনশন কনফিগার করা যায়, তাই আপনি অডিট‑ট্রেইল টপিকগুলোকে হাই‑ভ্যালু হিসেবে দীর্ঘ সময় ধরে রাখতে পারেন কিন্তু হাই‑ভলিউম টেলিমেট্রি দ্রুত ঘুরিয়ে দিতে পারেন।

কমপ্যাকশন: প্রতিটি কী‑এর সর্বশেষ মান রাখা

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

ইভেন্ট রি‑প্লে: স্টেট পুনর্নির্মাণ ও বাগ থেকে পুনরুদ্ধার

ইভেন্টগুলো স্টোর হওয়ায় আপনি সেগুলো রি‑প্লে করে স্টেট পুনর্নির্মাণ করতে পারেন:

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

প্রায়োগিকভাবে, রি‑প্লে নির্ধারিত হয় কনসিউমারের “কোথা থেকে পড়া শুরু করছে” (অফসেট) দ্বারা, যা টিমগুলিকে একটি শক্তিশালী সেফটি নেট দেয়।

নির্ভরযোগ্যতা ও ফল্ট‑টলারেন্সের বুনিয়াদি

Kafka এমনভাবে নির্মিত যাতে সিস্টেমের অংশগুলো বিফলে গেলেও ডেটা প্রবাহ অব্যাহত থাকে। এটি করে রেপ্লিকেশন, প্রতিটি পার্টিশনের “কে লিডার” সে সম্পর্কে স্পষ্ট নিয়ম, এবং কনফিগারেবল রাইট অ্যাকনলেজমেন্ট দিয়ে।

রেপ্লিকেশন: লিডার ও ফলোয়ার (উচ্চ পর্যায়ে)

প্রতিটি টপিক পার্টিশনের একটি লিডার ব্রোকার এবং এক বা একাধিক ফলোয়ার রিপ্লিকা থাকে। প্রোডিউসার ও কনসিউমাররা ঐ পার্টিশনের জন্য লিডারের সাথে যোগাযোগ করে।

ফলোয়াররা লিডারের ডেটা কপি করে রাখে। যদি লিডার ডাউন হয়, Kafka আপ‑টু‑ডেট থাকা ফলোয়ারদের মধ্যে থেকে একজনকে প্রমোট করে নতুন লিডার বানাতে পারে, যাতে পার্টিশন উপলব্ধ থাকে।

ব্রোকার ফেল্যুরের সময় কী ঘটে (সংক্ষিপ্ত)

যদি একটি ব্রোকার ফেল করে, যে পার্টিশনগুলো তা লিড করছিল তা সাময়িকভাবে অনুপলব্ধ হতে পারে। Kafka‑র কন্ট্রোলার এই ফেল খুঁজে বের করে এবং ঐ পার্টিশনগুলোর জন্য লিডার ইলেকশন ট্রিগার করে।

যদি কমপক্ষে একটি ফলোয়ার ইন‑সিঙ্ক থাকে, তা লিডার হিসেবে উঠতে পারে এবং ক্লায়েন্টরা আবার প্রোডিউস/কনসিউম করতে পারে। যদি কোনো ইন‑সিঙ্ক রিপ্লিকা না থাকে, Kafka কনফিগারেশন অনুযায়ী রাইট থামাতে পারে যাতে অ্যাকনলেজড ডেটা হারিয়ে না যায়।

ডিউরেবিলিটি: অ্যাকস ও রিপ্লিকেশন ফ্যাক্টর

দুইটি প্রধান কনফিগারেশন ডিউরেবিলিটি নির্ধারণ করে:

• রিপ্লিকেশন ফ্যাক্টর: প্রতিটি পার্টিশনের কয়টি কপি আছে (উদাহরণ: ৩ কপি তিনটি ব্রোকারে)।
• অ্যাকনলেজমেন্টস (acks): প্রোডিউসার কবে একটি রাইটকে সফল মনে করে।

কনসেপ্টুয়ালি:

• acks=0: প্রোডিউসার অপেক্ষা করে না—দ্রুত, কিন্তু মেসেজ হারাতে পারে।
• acks=1: লিডার রাইট কনফার্ম করে—ভালো, কিন্তু লিডার ফেল করলে সাম্প্রতিক মেসেজ হারাতে পারে।
• acks=all (বা -1): লিডার ইন‑সিঙ্ক রিপ্লিকাগুলো থেকে কনফার্মেশন পর্যন্ত অপেক্ষা করে—সুরক্ষিত, সাধারণত একটু ধীর।

রিট্রাই‑এর সময় ডুপ্লিকেট কমাতে টিমরা প্রায়ই নিরাপদ acks সেটিংসের সঙ্গে idempotent প্রোডিউসার এবং শক্ত কনজিউমার হ্যান্ডলিং ব্যবহার করে।

ল্যাটেন্সি বনাম নিরাপত্তার ট্রেড‑অফ

উচ্চতর নিরাপত্তা সাধারণত বেশি কনফার্মেশনের জন্য অপেক্ষা করা এবং আরো রিপ্লিকা সিঙ্ক রাখার প্রয়োজন হয়, যা ল্যাটেন্সি বাড়াতে এবং পিক থ্রুপুট কমাতে পারে।

কম ল্যাটেন্সি সেটিংস টেলিমেট্রি বা ক্লিকস্ট্রিমের মতো ক্ষেত্রে গ্রহণযোগ্য যেখানে মাঝে মাঝে ডেটা লস মানা যায়; কিন্তু পেমেন্ট, ইনভেন্টরি এবং অডিট লগ সাধারণত অতিরিক্ত নিরাপত্তা সাধিত করে।

ইভেন্ট‑ড্রিভেন আর্কিটেকচারে Kafka‑র ভূমিকা

ইভেন্ট‑ড্রিভেন আর্কিটেকচার (EDA) হলো এমন একটি উপায়ে সিস্টেম গঠন যেখানে ব্যবসার ঘটনা—একটি অর্ডার প্লেস করা, পেমেন্ট কনফার্ম হওয়া, প্যাকেজ শিপ হওয়া—কোকে ইভেন্ট হিসেবে উপস্থাপন করা হয় যাতে অন্য অংশগুলো সেগুলোর উপর প্রতিক্রিয়া জানাতে পারে।

ইভেন্ট পাবলিশ করুন, কনসিউমাররা প্রতিক্রিয়া জানাক

Kafka প্রায়শই EDA‑র কেন্দ্র হিসেবে কাজ করে—একটি শেয়ার করা “ইভেন্ট স্ট্রিম”। সার্ভিস A সরাসরি সার্ভিস B‑কে কল না করে, সার্ভিস A একটি Kafka টপিকে OrderCreated ইভেন্ট পাবলিশ করে। যে কোনও সংখ্যক সার্ভিস ঐ ইভেন্ট কনসিউম করে এবং কাজ করে—ইমেল পাঠানো, ইনভেন্টরি রিজার্ভ, ফ্রড চেক শুরু—বিনা সার্ভিস A‑কে জানা প্রয়োজন।

লুজ কাপলিং (কম সরাসরি নির্ভরশীলতা)

সার্ভিসগুলো ইভেন্টের মাধ্যমে যোগাযোগ করলে তাদের প্রত্যেকটি ইন্টারঅ্যাকশনের জন্য রিকোয়েস্ট/রেসপন্স এপিআই সমন্বয় করতে হয় না। এতে টিমের মধ্যে শক্ত কাপলিং কমে যায় এবং নতুন ফিচার যোগ করা সহজ হয়: আপনি একটি নতুন কনসিউমার পরিচয় করালেই চলবে, প্রোডিউসার পরিবর্তন করা লাগবে না।

অ্যাসিনক্রোনাস ওয়ার্কফ্লো এবং স্পাইক রেসিস্ট্যান্স

EDA স্বভাবতই অ্যাসিনক্রোনাস: প্রোডিউসার দ্রুত ইভেন্ট লিখে, কনসিউমাররা নিজেদের গতি অনুযায়ী প্রসেস করে। ট্রাফিক স্পাইক হলে Kafka সেই স্রোতকে বাফার করে যাতে ডাউনস্ট্রিম সিস্টেমগুলো একসাথে ভেঙে না পড়ে। কনসিউমাররা স্কেল‑আউট করে ক্যাচ‑আপ করতে পারে, এবং যদি একটি কনসিউমার সাময়িকভাবে ডাউন হয়, তা পুনরায় শুরু করে যেখানে থেমেছিল।

একটি ব্যবহারিক মানসিক মডেল

Kafka‑কে ভাবুন সিস্টেমের “অ্যাক্টিভিটি ফিড” হিসেবে। প্রোডিউসাররা স্থিতি প্রকাশ করে; কনসিউমাররা তাদের যা যা দরকার তা সাবস্ক্রাইব করে। এই প্যাটার্নটি রিয়েল‑টাইম ডাটা পাইপলাইন ও ইভেন্ট‑ড্রিভেন ওয়ার্কফ্লো সক্রিয় করে এবং সার্ভিসগুলোকে সহজ ও স্বাধীন রাখে।

আধুনিক সিস্টেমে Kafka‑র সাধারণ ব্যবহার ক্ষেত্র

Kafka সাধারণত সেখানে ব্যবহৃত হয় যেখানে টিমগুলোকে প্রচুর ছোট "ঘটা ঘটেছে" (ইভেন্ট) বারান্দা দ্রুত, বিশ্বাসযোগ্যভাবে এবং একাধিক কনসিউমারদের পুনরায় ব্যবহারযোগ্যভাবে পাঠাতে হয়।

অ্যাক্টিভিটি ট্র্যাকিং ও অডিট লগ

অ্যাপগুলো প্রায়ই একটি_APPEND‑অনলি ইতিহাস রাখে: ইউজার সাইন‑ইন, পারমিশন পরিবর্তন, রেকর্ড আপডেট, বা অ্যাডমিন অ্যাকশন। Kafka কেন্দ্রিয় স্ট্রিম হিসেবে কাজ করে যাতে সিকিউরিটি টুল, রিপোর্টিং ও কমপ্লায়েন্স এক্সপোর্ট একই সোর্স পড়তে পারে—প্রোডাকশন DB‑তে অতিরিক্ত লোড ছাড়াই। ইভেন্টগুলো একটি সময় ধরে রাখা হলে বাগ বা স্কিমা পরিবর্তনের পরেও অডিট ভিউ পুনঃনির্মাণ করা যায়।

মাইক্রোসার্ভিস যোগাযোগ ইভেন্টের মাধ্যমে

সার্ভিসগুলো সরাসরি একে অপরকে কল না করে ইভেন্টগুলো পাবলিশ করে, যেমন “order created” বা “payment received।” অন্য সার্ভিসগুলো সাবস্ক্রাইব করে এবং নিজেদের সময়ে প্রতিক্রিয়া জানায়। এতে কড়াকড়ি কাপলিং কমে, আংশিক আউটেজেও সিস্টেম কাজ চালিয়ে যেতে পারে, এবং কেবল বিদ্যমান ইভেন্ট স্ট্রিম খেয়েই নতুন ক্ষমতা যোগ করা সহজ হয় (যেমন ফ্রড চেক)।

অ্যানালিটিক্স ও ওয়্যারহাউসে ডেটা পাইপলাইন

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

IoT ও টেলিমেট্রি যেখানে ট্রাফিক স্পাইকি হয়

সেন্সর, ডিভাইস, ও অ্যাপ টেলিমেট্রি প্রায়ই স্পাইকে আসে। Kafka সেই বাম্পগুলো শোষণ করতে পারে, নিরাপদে বাফার করে, এবং ডাউনস্ট্রিম প্রসেসিংকে ক্যাচ‑আপ করাতে দেয়—মনিটরিং, অ্যালার্টিং, ও দীর্ঘমেয়াদী বিশ্লেষণের জন্য উপযোগী।

Kafka একোসিস্টেম: Connect, Streams, ও টুলিং

Kafka শুধু ব্রোকার ও টপিক নয়। বেশিরভাগ টিম সহায়ক টুলগুলোর ওপর নির্ভর করে যা দৈনন্দিন ডেটা মুভমেন্ট, স্ট্রিম প্রসেসিং, ও অপারেশনকে বাস্তবসম্মত করে তোলে।

Kafka Connect: কাস্টম কোড ছাড়াই ডেটা মুভ করা

Kafka Connect হলো Kafka‑এর ইন্টিগ্রেশন ফ্রেমওয়ার্ক যা ডেটা Kafka‑তে আনা (sources) এবং Kafka থেকে পাঠানো (sinks) সহজ করে। এক‑অফ পাইপলাইন তৈরি না করে আপনি Connect চালিয়ে কনফিগারেশন দিয়ে সংযোগ স্থাপন করেন।

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

Kafka Streams: আপনার অ্যাপে রিয়েল‑টাইম প্রসেসিং

যদি Connect ইন্টিগ্রেশনের জন্য হয়, Kafka Streams হলো কম্পিউটেশনের জন্য। এটি একটি লাইব্রেরি যা আপনার অ্যাপে যোগ করে স্ট্রিমগুলো বাস্তবে ট্রান্সফর্ম করতে পারে—ফিল্টার, এনরিচ, স্ট্রীম জয়েন, এবং এগ্রিগেট (যেমন “orders per minute”)।

Streams অ্যাপগুলো টপিক থেকে পড়ে এবং টপিকে লিখে, তাই ইভেন্ট‑ড্রিভেন সিস্টেমে সুপ্রকৃতি ভাবে ফিট করে এবং আরও ইনস্ট্যান্স যোগ করলে স্কেল করে।

স্কিমা ম্যানেজমেন্ট: ইভেন্টগুলো সঙ্গতিপূর্ণ রাখা

একাধিক টিম ইভেন্ট পাবলিশ করলে কনসিস্টেন্সি জরুরি। স্কিমা ম্যানেজমেন্ট (প্রায়ই একটি স্কিমা রেজিস্ট্রি দ্বারা) নির্ধারণ করে ইভেন্টে কী ফিল্ড থাকা উচিত এবং কীভাবে এগুলো সময়ের সঙ্গে বিকশিত হবে। এতে প্রোডিউসার কোনো ফিল্ড রিনেম করলে কনসিউমার ভেঙে না যায়।

টুলিং: যেসব মেট্রিক জরুরি

Kafka অপারেশনালি সংবেদনশীল, তাই বেসিক মনিটরিং অপরিহার্য:

• কনসিউমার লাগ: কনসিউমার পিছিয়ে আছে কি না?
• থ্রুপুট: সেকেন্ডে কত ইভেন্ট যাচ্ছে?
• এররস: ব্যর্থ ফেচ, প্রোডিউস এরর, কনেক্টর টাস্ক ফেইল

বেশি টিম ম্যানেজমেন্ট UI এবং ডেপ্লয়মেন্ট, টপিক কনফিগারেশন, এবং অ্যাক্সেস কন্ট্রোল নীতির অটোমেশনও ব্যবহার করে (দেখুন /blog/kafka-security-governance)।

ডেলিভারি গ্যারান্টি ও প্রসেসিং প্যাটার্ন

Kafka কেবল “টেকসই লগ + কনসিউমার” না—বেশিরভাগ টিম আসলে জানতে চায়: ওকে, আমি কি প্রতিটি ইভেন্ট একবারই প্রসেস করব, আর ব্যর্থ হলে কী হবে? Kafka আপনাকে বিল্ডিং ব্লক দেয়, এবং আপনিই ট্রেড‑অফগুলো বাছবেন।

ডেলিভারি গ্যারান্টি (উচ্চ স্তরে)

At-most-once: আপনি ইভেন্ট হারাতে পারেন, কিন্তু ডুপ্লিকেট হবে না। উদাহরণ: কনসিউমার অফসেট আগে কমিট করে এবং তারপর ক্র্যাশ করে।

At-least-once: ইভেন্ট হারাবে না, কিন্তু ডুপ্লিকেট হতে পারে (উদাহরণ: কনসিউমার একটি ইভেন্ট প্রসেস করে, ক্র্যাশ করে, এবং আবার রি‑প্রসেস করে)। এটি সাধারণ ডিফল্ট প্যাটার্ন।

Exactly-once: উভয়ই—না হারানো, না ডুপ্লিকেট—লক্ষ্য করে। Kafka-তে এটি সাধারণত ট্রানজেকশনাল প্রোডিউসার ও সামঞ্জস্যপূর্ণ প্রসেসিং (প্রায়ই Kafka Streams) দিয়ে অর্জিত হয়। শক্তিশালী কিন্তু বেশি সীমাবদ্ধ এবং সাবধানে সেটআপ প্রয়োজন।

আইডেমপটেন্সি ও ডুপ-ডিটেকশন

প্র্যাকটিসে অনেক সিস্টেম at-least-once গ্রহণ করে এবং সুরক্ষা যোগ করে:

• Idempotent writes: “ইভেন্ট প্রয়োগ” ধাপ বারবার করা নিরাপদ করুন (উদা: upserts, কন্ডিশনাল আপডেট, ইউনিক কী)।
• ডুপ্লিকেশন অপসারণ: ইভেন্ট আইডি বা বিজনেস কী সংরক্ষণ করে একটি উইন্ডোতে রিপিটস উপেক্ষা করুন।

কনসিউমার অফসেট: আপনার “বুকমার্ক”

কনসিউমার অফসেট হলো একটি পার্টিশনে সর্বশেষ প্রসেস করা রেকর্ডের অবস্থান। আপনি যখন অফসেট কমিট করেন, বলছেন, “আমি এখান পর্যন্ত শেষ করেছি।” খুব আগেই কমিট করলে লোকসান, খুব দেরিতে করলে ডুপ্লিকেট থাকার সম্ভাবনা বাড়ে।

রিট্রাই ও পয়জন মেসেজ

রিট্রাই সীমাবদ্ধ ও দৃশ্যমান হওয়া উচিত। একটি সাধারণ প্যাটার্ন:

1. অস্থায়ী ত্রুটির ক্ষেত্রে ব্যাকঅফসহ রিট্রাই করুন,
2. তারপর ব্যর্থ রেকর্ডটি একটি ডেড‑লেটার টপিক-এ পাঠান তদন্ত ও পুনরায় চালানোর জন্য।

এটি একটি “পয়জন মেসেজ” পুরো গ্রুপকে ব্লক করা থেকে রক্ষা করে, একই সাথে ডেটা পরবর্তী ফিক্সের জন্য সংরক্ষণ করে।

নিরাপত্তা ও গভর্ন্যান্স বিবেচনা

Kafka প্রায়ই ব্যবসায়িকভাবে গুরুত্বপূর্ণ ইভেন্ট বহন করে (অর্ডার, পেমেন্ট, ইউজার অ্যাক্টিভিটি)। তাই নিরাপত্তা ও গভর্ন্যান্স ডিজাইনের অংশ হওয়া উচিত, পরে যোগ করার মতো না।

প্রমাণীকরণ ও অনুমোদন

প্রমাণীকরণ বলে “আপনি কে?”; অনুমোদন বলে “আপনি কী করতে পারেন?” Kafka‑তে সাধারণত SASL (উদা: SCRAM বা Kerberos) দিয়ে প্রমাণীকরণ করা হয়, আর অনুমোদন ACLs (টপিক, কনসিউমার গ্রুপ, ক্লাস্টার স্তরে) দিয়ে প্রয়োগ করা হয়।

একটি বাস্তবিক প্যাটার্ন হলো লিস্ট‑প্রিভিলেজ: প্রোডিউসার শুধু তাদের টপিকে লিখতে পারে, কনসিউমার শুধু তাদের দরকারি টপিক পড়তে পারে। এতে ভ্রান্ত ডেটা‑এক্সপোজার কমে এবং যদি ক্রেডেনশিয়াল লিক হয় তাতে ক্ষতি সীমিত হয়।

ট্রান্সিটে এনক্রিপশন (TLS)

TLS ক্লায়েন্ট, ব্রোকার এবং টুলিংয়ের মধ্যকার ডেটা এনক্রিপ্ট করে। TLS ছাড়া ইভেন্টগুলো ইন্টারনাল নেটওয়ার্কে ইন্টারসেপ্ট করা যেতে পারে—শুধু পাবলিক ইন্টারনেট নয়। TLS ব্রোকারের পরিচয় যাচাই করে MAN‑IN‑THE‑MIDDLE আক্রমণও রুখে দেয়।

মাল্টি‑টেন্যান্ট Kafka ও নামকরণ কনভেনশন

যখন একাধিক টিম একটি ক্লাস্টার শেয়ার করে, গার্ডরেইল প্রয়োজন। স্পষ্ট টপিক নেমিং কনভেনশন (উদাহরণ: \u003cteam\u003e.\u003cdomain\u003e.\u003cevent\u003e.\u003cversion\u003e) মালিকানা স্পষ্ট করে এবং টুলিংকে কনসিস্টেন্ট নীতি প্রয়োগে সাহায্য করে।

নেমিংয়ের সঙ্গে কোটা ও ACL টেমপ্লেট জোড়া লাগান যাতে একটি জোরালো ওয়ার্কলোড অন্যদের অপুষ্ট না করে, এবং নতুন সার্ভিসগুলো নিরাপদ ডিফল্ট নিয়ে শুরু করে।

ডেটা গভর্ন্যান্স: PII, রিটেনশন, ও সমন্বয়

Kafka‑কে ইভেন্ট ইতিহাসের সিস্টেম অফ রেকর্ড হিসাবে বিবেচনা করুন কেবল তখনই যখন তা প্রত্যাশিত। ইভেন্টে PII থাকলে ডেটা মিনিমাইজেশন করুন (পূর্ণ প্রোফাইল না পাঠিয়ে আইডি পাঠান), ফিল্ড‑লেভেল এনক্রিপশন বিবেচনা করুন, এবং কোন টপিক সংবেদনশীল তা ডকুমেন্ট করুন।

রিটেনশন সেটিংস আইনি ও ব্যবসায়িক চাহিদার সাথে মিলিয়ে রাখুন। যদি নীতি বলে “30 দিনের পরে মুছে ফেল”, তাহলে 6 মাস ধরে রাখা ঠিক নয়। নিয়মিত পর্যালোচনা ও অডিট কনফিগারেশনগুলো সিস্টেম বিবর্তনের সাথে সামঞ্জস্য রাখে।

Kafka চালানো: টিমগুলোকে কী পরিকল্পনা করতে হবে

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

ক্যাপাসিটি প্ল্যানিং মূলনীতি

Kafka ক্যাপাসিটি মূলত একটি গণিত সমস্যা যেটা নিয়মিত পুনর্বিবেচনা করা দরকার। বড় লিভারগুলো হলো পার্টিশন (প্যারালালিজম), থ্রুপুট (MB/s ইন ও আউট), এবং স্টোরেজ বৃদ্ধি (রিটেনশন কতো লম্বা)।

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

দৈনন্দিন অপারেশনাল কাজ

সার্ভার চালু রাখার বাইরে রুটিন কাজ আশা করুন:

• আপগ্রেড: রোলিং আপগ্রেড পরিকল্পনা করুন, ক্লায়েন্ট সামঞ্জস্য পরীক্ষা করুন, ও ট্র্যাফিক কম olan সময়ে পরিবর্তন শিডিউল করুন।
• রিব্যালেন্সিং: কনসিউমার গ্রুপ রিব্যালেন্স সাময়িক পজ দিতে পারে; নিরাপদ ডেপ্লয়মেন্ট প্যাটার্ন ও স্পষ্ট মালিকানা থাকা ভালো।
• ইনসিডেন্ট রেসপন্স: ব্রোকার ফেল, ডিস্ক‑পূর্ণ, বা ভুল কনফিগারেশন সম্পন্ন প্রোডিউসার যা টপিক প্লাডিং করে—এসবের জন্য প্লেবুক রাখুন।

খরচ নির্ধারণ ও ডিপ্লয়মেন্ট পছন্দ

খরচ আসে মূলত ডিস্ক, নেটওয়ার্ক আউটগোয়িং, এবং ব্রোকারের সংখ্যা/আকার থেকে। ম্যানেজড Kafka স্ট্যাফিং ও আপগ্রেড সহজ করতে পারে, যেখানে সেলফ‑হোস্ট করা স্কেলে সস্তা হতে পারে যদি আপনার কাছে দক্ষ অপারেটর থাকে। ট্রেড‑অফটি টাইম‑টু‑রিকভারি ও অন‑কল বোঝা।

কী মাপবেন (যাতে অনুমান না করতে হয়)

টিমগুলো সাধারণত মনিটর করে:

• এন্ড‑টু‑এন্ড ল্যাটেন্সি (প্রোডিউস থেকে কনসিউম পর্যন্ত)
• কনসিউমার লাগ (কত পিছিয়ে আছে)
• ব্রোকার হেলথ (ডিস্ক ইউসেজ, আন্ডার‑রেপ্লিকেটেড পার্টিশন, রিকোয়েস্ট এরর রেট)

ভালো ড্যাশবোর্ড ও অ্যালার্ট Kafka‑কে একটি ‘রহস্য বাক্স’ থেকে একটি বোঝা‑যাই service‑এ পরিণত করে।

কখন Kafka ব্যবহার করবেন (এবং কখন না)

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

Kafka বেছে নেওয়ার উপযুক্ত সময়

Kafka সাধারণত ভাল কাজ করে যখন:

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

কখন Kafka অতিরিক্ত ভারী হতে পারে

যদি আপনার চাহিদা সরল হয়, Kafka বেশি জটিল হতে পারে:

• দুইটি সার্ভিসের মধ্যে একটি কম‑ভলিউম কিউ দরকার হলে
• অস্থায়ী কাজ (ব্যাকগ্রাউন্ড জব) যেখানে রি‑প্লে মূল্যবান নয়
• এমন টিম যারা একটি বিতরণকৃত সিস্টেম অপারেট করার সময় পান না

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

বিকল্প এবং পরিপূরক টুল

• RabbitMQ: ক্লাসিক ওয়ার্ক কিউ ও রাউটিং প্যাটার্নের জন্য চমৎকার।
• NATS: লাইটওয়েট মেসেজিং, নিম্ন ল্যাটেন্সি।
• Cloud pub/sub: যদি আপনি ম্যানেজড ইনফ্রা চান এবং সহজ অপস পুরো পছন্দ করেন।

Kafka ডাটাবেস (সিস্টেম অফ রেকর্ড), ক্যাশ (দ্রুত রিড), এবং ব্যাচ ETL টুলগুলোর (বড় পিরিয়ডিক ট্রান্সফর্মেশন) সাথে পরিপূরক—প্রতিস্থাপন নয়।

দ্রুত সিদ্ধান্ত চেকলিস্ট

প্রশ্ন করুন:

1. আমাদের কি বহু কনসিউমার ও রি‑প্লে দরকার?
2. থ্রুপুট উল্লেখযোগ্যভাবে বাড়বে কি?
3. রিটেনশন/ইভেন্ট ইতিহাস কি প্রয়োজনীয়?
4. আমরা অপারেশনাল মালিকানা সামলাতে পারি (বা ম্যানেজড Kafka ব্যবহার করব)?
5. আমরা ইভেন্ট স্ট্রিমিং করছি, শুধু কমান্ড/টাস্ক পাচ্ছি না?

আপনি বেশিরভাগ প্রশ্নে “হ্যাঁ” বললে, Kafka সাধারণত যুক্তিযুক্ত পছন্দ।

শুরু করা: একটি সরল অ্যাডপশন পথ

Kafka সবচেয়ে ভালো মানে যখন একটি শেয়ার করা “রিয়েল‑টাইম সোর্স অফ ট্রুথ” দরকার: বহু সিস্টেম যা ফ্যাক্ট প্রোডিউস করে (অর্ডার তৈরি, পেমেন্ট অনুমোদন, ইনভেন্টরি পরিবর্তন) এবং বহু সিস্টেম সেগুলো খেয়ে পাইপলাইন, অ্যানালিটিক্স, ও প্রতিক্রিয়াশীল ফিচার চালায়।

ধাপ 1: একটি সুনির্দিষ্ট কেস বেছে নিন

একটি সংকীর্ণ, উচ্চ‑মূল্য প্রবাহ দিয়ে শুরু করুন—যেমন downstream সার্ভিসগুলোর (ইমেল, ফ্রড চেক, ফুলফিলমেন্ট) জন্য “OrderPlaced” ইভেন্ট পাবলিশ করা। প্রথম দিনেই Kafka‑কে catch‑all কিউ বানাবেন না।

ধাপ 2: আপনার ইভেন্ট ও টপিকগুলো নির্ধারণ করুন

লিখে রাখুন:

• ইভেন্ট: কী ঘটেছে, ব্যবসায়িক শব্দে
• টপিক: ঐ ইভেন্ট কোথায় থাকবে (প্রায়ই প্রতি ইভেন্ট টাইপ বা ডোমেইনে একটি টপিক)
• কনসিউমার: কোন টিম/সার্ভিস ইভেন্টগুলো দরকার এবং কেন

প্রাথমিক স্কিমাগুলো সাদামাটা রাখুন (টাইমস্ট্যাম্প, আইডি, স্পষ্ট ইভেন্ট নাম)। সিদ্ধান্ত নিন আপনি স্কিমা আগে‑থেকে প্রয়োগ করবেন না কি সময়ের সঙ্গে সাবধানে বিকাশ করবেন।

ধাপ 3: মালিকানা ও অপারেটিং মূলনীতি স্থাপন করুন

Kafka সফল হয় যখন কারো মালিকানা থাকে:

• টপিক সৃষ্টি ও নামকরণ কনভেনশন
• রিটেনশন ও অ্যাক্সেস নীতি
• অন‑কল দায়িত্ব এবং রানবুক

শুরুতেই মনিটরিং যোগ করুন (কনসিউমার লাগ, ব্রোকার হেলথ, থ্রুপুট, এরর রেট)। যদি এখনো প্ল্যাটফর্ম টিম না থাকে, managed অপশন দিয়ে শুরু করুন এবং স্পষ্ট সীমা নির্ধারণ করুন।

ধাপ 4: একটি “পাতলা” প্রথম পাইপলাইন তৈরি করুন

একটি সিস্টেম থেকে ইভেন্ট প্রোডিউস করুন, একটি জায়গায় কনসিউম করুন, এবং এন্ড‑টু‑এন্ড লুপটি প্রমান করুন। তারপর ধীরে ধীরে কনসিউমার, পার্টিশন, ও ইন্টিগ্রেশন বাড়ান।

ফাস্ট‑ট্র্যাক প্রোটোটাইপে Koder.ai‑র মতো টুলগুলো সাহায্য করতে পারে (React UI, Go ব্যাকএন্ড, PostgreSQL) এবং চার্ট‑চালিত ওয়ার্কফ্লো দিয়ে দ্রুত Kafka প্রোডিউসার/কনসিউমার যোগ করতে দেয়। এটি অভ্যন্তরীণ ড্যাশবোর্ড ও হালকা সার্ভিস তৈরিতে সহায়ক, প্ল্যানিং মোড, সোর্স‑কোড এক্সপোর্ট, ডিপ্লয়/হোস্টিং, এবং স্ন্যাপশট‑রোলব্যাকের মতো ফিচার সহ।

আপনি যদি এটি ইভেন্ট‑ড্রাইভেনভাবে ম্যাপ করতে চান দেখুন /blog/event-driven-architecture. কস্ট ও এনভায়রনমেন্ট পরিকল্পনার জন্য দেখুন /pricing.