Apache Kafka: topic, partition ও consumer group

Apache Kafka একটি distributed event log। Producer event যোগ করে, Kafka টেকসইভাবে রাখে, আর consumer নিজের গতিতে পড়ে। সাধারণ queue-র মতো নয়, পড়ার পর message মুছে যায় না। নির্দিষ্ট retention সময় পর্যন্ত থাকে, তাই অনেক consumer পড়তে পারে এবং ইতিহাস আবার চালানো যায়।

মূল ধারণা

• Topic: নামযুক্ত stream, যেমন orders।
• Partition: topic ভাগ হয় partition-এ। প্রতিটি partition ক্রমানুসারে append-only log। Kafka এভাবেই scale করে।
• Offset: partition-এ message-এর অবস্থান। Consumer মনে রাখে কোথায় থেমেছিল।
• Broker: একটি Kafka server। Cluster-এ কয়েকটি থাকে।

ক্রম ও key

ক্রম নিশ্চিত শুধু একটি partition-এর ভেতরে। Producer key দিয়ে partition বাছে: একই key-র (যেমন user_id) সব message একই partition-এ যায় এবং ক্রমে থাকে।

Consumer group

একটি consumer group-এর consumer-রা কাজ ভাগ করে: প্রতিটি partition group-এর ঠিক একজন consumer পড়ে। Consumer বাড়ালে parallelism বাড়ে, partition সংখ্যা পর্যন্ত। অন্য group পায় stream-এর নিজস্ব পূর্ণ কপি। এভাবে একটি event আলাদাভাবে billing, analytics ও search-এ যেতে পারে।

টেকসই হওয়া

প্রতিটি partition-এর একটি leader ও অন্য broker-এ replica থাকে। Replication factor ৩ হলে একটি broker মরলেও data যায় না। Producer কতগুলো acknowledgement-এর অপেক্ষা করবে তা বাছতে পারে, যা গতি ও নিরাপত্তার লেনদেন। নতুন Kafka সংস্করণ ZooKeeper-এর বদলে cluster metadata নিজেই সামলায় (KRaft)।

কখন ব্যবহার করবেন

• বিশাল volume-এর event stream, log ও metric।
• একই data-র অনেক স্বাধীন consumer।
• Event sourcing ও replay।
• সিস্টেমগুলোর মধ্যে data pipeline।

কখন নয়

কম volume-এর সাধারণ background job queue-র জন্য RabbitMQ বা SQS-এর মতো task queue চালানো সহজ। Kafka শক্তিশালী, তবে পরিচালনার খরচ আছে।

মূল কথা: Kafka-কে ভাবুন টেকসই, আবার চালানো যায় এমন log হিসেবে। Key সাবধানে বাছুন, parallelism অনুযায়ী partition ঠিক করুন, আর যেখানে এর শক্তি লাগে সেখানে ব্যবহার করুন।

---

System Design সিরিজ, পর্ব ২ (building block): 2 নম্বর (মোট 14)। আগের লেখা: Redis internals: কেন দ্রুত, কীভাবে নিরাপদে ব্যবহার করবেন.