Event-Driven Architecture - কাউকে না ডেকে সবাইকে জানানো

০০ যে প্রশ্নগুলোর উত্তর খুঁজবো

সেশন ০৮ এ আমরা queue শিখেছি। একটা job queue তে যায়, আর একজন worker সেটা তুলে নিয়ে কাজ করে। কিন্তু একটা ঘটনার খবর যদি একসাথে পাঁচ জায়গায় পৌঁছাতে হয়? আর ছয় মাস পরে আরো তিনটা নতুন জায়গা যোগ হয়?

এই সেশনে আমরা দেখবো, একটা service কীভাবে শুধু “এটা ঘটেছে” বলে চুপ করে যায়, আর যার দরকার সে নিজেই খবরটা নিয়ে নেয়। এই ধরনের design কে বলে event-driven architecture। শেষে আপনি বুঝবেন, Kafka কেন এত জনপ্রিয়, আর কোথায় এই পথে না যাওয়াই ভালো।

০১ Order service নিজেই সবাইকে call করলে সমস্যা কোথায়?

রমজানের এক বিকেল, ৫টা ৪০। ইফতারের আর বিশ মিনিট বাকি। “ঝটপট” নামের food delivery app এ প্রতি সেকেন্ডে প্রায় ৫০টা order ঢুকছে। রুবেল অফিসে বসে dashboard দেখছে, আর তার বুক ধুকপুক করছে। হঠাৎ checkout এর graph লাল হয়ে গেলো। SMS gateway ধীর হয়ে গেছে, আর সেই কারণে মানুষ order ই দিতে পারছেন না। ঠিক তখন Slack এ loyalty team এর মেসেজ এলো: “ভাই, order হলে আমাদের service কেও একটা call দিয়েন।”

রুবেল order service এর দায়িত্বে। দুই বছর আগে এই service এর কাজ ছিলো একটাই: order টা database এ লেখা। তারপর একে একে অনুরোধ এসেছে। Restaurant কে জানাতে হবে। Rider খুঁজতে হবে। Customer কে SMS দিতে হবে। Loyalty point দিতে হবে। Analytics এ হিসাব পাঠাতে হবে। প্রতিটা অনুরোধে রুবেল order service এ আরেকটা call যোগ করেছে:

এই design এ তিনটা সমস্যা লুকিয়ে আছে:

1. সবচেয়ে ধীর service সবাইকে ধীর করে: Order service পাঁচটা call একটার পর একটা করে। সব মিলিয়ে প্রায় 990ms লাগে, আর এর বেশিরভাগটাই SMS gateway এর। খারাপ দিনে SMS gateway 5 সেকেন্ড পর timeout দেয়, তখন customer ছয় সেকেন্ড ধরে spinner দেখেন।
2. একজন down হলে order ই হয় না: প্রতিটা service আলাদাভাবে 99.9% সময় ঠিক থাকে। কিন্তু order সফল হতে পাঁচটাকেই একসাথে ঠিক থাকতে হয়। ০.৯৯৯ কে পাঁচবার গুণ করলে আসে প্রায় ০.৯৯৫, মানে ৯৯.৫%। দিনে দেড় লাখ order হলে প্রায় ৭৫০টা order শুধু এই কারণে fail করে। অথচ SMS না গেলেও খাবারটা পৌঁছাতে কোনো বাধা ছিলো না।
3. প্রতিটা নতুন team এর জন্য order service বদলাতে হয়: Loyalty team এর জন্য নতুন code, নতুন deploy, নতুন ঝুঁকি। পরের মাসে fraud team আসবে। Order service এর মূল কাজ ছোট, কিন্তু তাকে বাকি সবার খবর রাখতে হয়।

একটা service যখন অন্য অনেক service কে নাম ধরে চেনে আর তাদের উপর নির্ভর করে, তখন তাকে বলে tight coupling। একটার সমস্যা তখন সবার সমস্যা হয়ে যায়।

০২ “এটা করুন” আর “এটা ঘটেছে” এর মধ্যে পার্থক্য কী?

রুবেলের পুরোনো code এ order service প্রত্যেককে একটা করে নির্দেশ পাঠায়: “rider খুঁজুন”, “SMS পাঠান”, “point দিন”। এমন নির্দেশকে বলে command।

এবার একটু অন্যভাবে ভাবুন। Order service শুধু একটা ঘোষণা দিলো: “Order #5821 এইমাত্র হয়েছে।” কাকে কী করতে হবে, সে বললো না। যার দরকার, সে নিজেই শুনে নিজের কাজ করবে। এমন ঘোষণাকে বলে event।

পাড়ায় রিকশায় মাইক বেঁধে যে ঘোষণা হয়, সেটার কথা ভাবুন: “আগামীকাল সকাল দশটা থেকে পানি থাকবে না।” যিনি ঘোষণা দিচ্ছেন, তিনি আলাদা করে কোনো বাড়িতে ফোন করেন না। কে শুনলো, সেটাও তিনি জানেন না। যার দরকার, তিনি শুনে আগেভাগে পানি ধরে রাখেন। Event ঠিক এমনই একটা ঘোষণা।

০৩ একটা event অনেক service এর কাছে পৌঁছায় কীভাবে?

সেশন ০৮ এর queue এ একটা নিয়ম ছিলো: একটা job একজন worker ই পায়। Worker রা একই কাজের জন্য একে অপরের সাথে প্রতিযোগিতা করে। Video encode এর জন্য এটা ঠিক আছে, কারণ একটা video একবার encode করলেই যথেষ্ট।

কিন্তু রুবেলের OrderPlaced event টা restaurant, rider, SMS, loyalty আর analytics, সবারই দরকার। এখানে চাই উল্টো নিয়ম: প্রত্যেকে নিজের আলাদা কপি পাবে। এই নিয়মের নাম pub/sub (publish/subscribe)।

Pub/sub এ তিনটা শব্দ বারবার আসবে:

• Publisher: যে event পাঠায়। এখানে order service।
• Topic: একটা নাম দেওয়া চ্যানেল, যেখানে একই ধরনের event জমা হয়। যেমন, order সংক্রান্ত সব event যায় orders topic এ। Radio এর একটা চ্যানেলের মতো।
• Subscriber: যে একটা topic এ নাম লেখায় (subscribe করে), আর সেই topic এর প্রতিটা event এর কপি পায়।

রুবেল এবার order service কে বদলে দিলো। Order service এখন order টা নিজের database এ লেখে, orders topic এ একটা OrderPlaced event publish করে, আর customer কে উত্তর দিয়ে দেয়। বাকি সবাই নিজেরাই topic থেকে event পড়ে নেয়:

ফলাফলটা দেখুন। Checkout এখন 990ms এর বদলে প্রায় 50ms এ শেষ হয়। SMS gateway আধা ঘণ্টা down থাকলেও order আসতে থাকে। SMS service ফিরে এসে জমে থাকা event গুলো পড়ে, আর দেরিতে হলেও SMS পাঠিয়ে দেয়। সবচেয়ে মজার ঘটনা ঘটলো পরের মাসে। Fraud team এসে শুধু orders topic এ subscribe করলো। রুবেলকে order service এর একটা লাইনও বদলাতে হলো না।

০৪ Kafka কেন queue নয়, একটা log?

রুবেলের team topic চালানোর জন্য Kafka বেছে নিলো। সেশন ০৮ এ এক লাইনে বলা হয়েছিলো, Kafka ঠিক queue নয়, একটা log। এবার কথাটার মানে খুলে দেখি।

Log মানে একটা খাতা

এখানে log মানে error log না। Log মানে এমন একটা খাতা, যেখানে লেখা শুধু শেষে যোগ হয়। আগের কোনো লাইন মোছা বা বদলানো হয় না। দোকানের হিসাবের খাতার মতো: নতুন বিক্রি হলে নিচে নতুন লাইন লেখা হয়।

Queue আর log এর সবচেয়ে বড় পার্থক্য হলো, পড়লে কী হয়। Queue তে worker ACK পাঠালে message মুছে যায়। Kafka তে কেউ পড়লেও event মোছে না। খাতাটা যেমন ছিলো তেমনই থাকে। শুধু যে পড়ছে, সে মনে রাখে কোন লাইন পর্যন্ত পড়া হয়েছে।

এই ছবির চারটা শব্দ চিনে নিন:

• Partition: একটা topic এর ভেতরের এক একটা খাতা। একটা topic এ কয়েকটা partition থাকে, যাতে কাজ কয়েকটা machine এ ভাগ হয়ে যায়। প্রতিটা partition এর ভেতরে event গুলো লেখার ক্রমেই থাকে।
• Offset: Partition এর ভেতরে প্রতিটা event এর ক্রমিক নম্বর: ০, ১, ২, ৩… খাতার লাইন নম্বরের মতো। Consumer মনে রাখে, সে কোন offset পর্যন্ত পড়েছে।
• Retention: Kafka একটা event কতদিন রেখে দেবে, সেই সময়সীমা। Kafka এর default হলো ৭ দিন। সময় পার হলে পুরোনো event গুলো মুছে যায়, কেউ পড়ুক বা না পড়ুক।
• Replay: পুরোনো offset এ ফিরে গিয়ে event গুলো আবার শুরু থেকে পড়া। Event মোছে না বলেই এটা সম্ভব।

Replay কেন এত কাজের

ছবিতে নতুন Loyalty service টা দেখুন। সে আজই চালু হলো, কিন্তু সে চায় গত সাত দিনের order এর point ও দিতে। Queue হলে এটা অসম্ভব ছিলো, কারণ পুরোনো message গুলো অনেক আগেই মুছে গেছে। Kafka তে Loyalty শুধু বলে, “আমি সবচেয়ে পুরোনো offset থেকে পড়বো।” সাত দিনের সব order সে আবার পায়।

Replay আরেক জায়গাতেও খুব কাজে লাগে। ধরুন analytics service এর code এ একটা bug ছিলো, আর দুই দিন ধরে ভুল হিসাব হয়েছে। Bug ঠিক করে offset দুই দিন পিছিয়ে দিলেই সব হিসাব আবার ঠিকঠাক তৈরি হয়।

খরচ কেমন?

রুবেল একটা হিসাব করলো। দিনে দেড় লাখ order। প্রতি order এ গড়ে ৫টা event (placed, accepted, rider assigned, picked up, delivered)। প্রতিটা event প্রায় 1 KB।

• দিনে event: ১,৫০,০০০ × ৫, মানে সাড়ে সাত লাখ।
• দিনে জায়গা: সাড়ে সাত লাখ × 1 KB, মানে প্রায় 750 MB।
• ৭ দিনের retention: প্রায় 5.25 GB।
• নিরাপত্তার জন্য Kafka প্রতিটা partition এর ৩টা কপি রাখে: সব মিলিয়ে প্রায় 16 GB।

16 GB একটা সাধারণ laptop এর disk এও ধরে যায়। সাত দিনের পুরো ইতিহাস রাখার খরচ তাই খুবই কম।

Consumer group: কাজ ভাগ, আবার সবাই পুরোটা পায়

ইফতারের আগে প্রতি সেকেন্ডে ৫০টা order আসে। Rider service এর একটা machine এত event সামলাতে পারে না। তাই rider team তিনটা machine চালায়। কিন্তু একই event তিনটা machine পেলে একই order এর জন্য তিনজন rider পাঠানো হবে।

এর সমাধান consumer group। একই কাজের জন্য চলা কয়েকটা consumer একটা group এর নামে চলে। Kafka তখন partition গুলো group এর সদস্যদের মধ্যে ভাগ করে দেয়:

নিয়ম দুটো:

1. একটা group এর ভেতরে প্রতিটা partition ঠিক একজন consumer পড়ে। তাই একটা event group এর মধ্যে একবারই process হয়। এটা queue এর মতো আচরণ।
2. আলাদা group হলে প্রত্যেক group পুরো topic পায়। Rider group আর SMS group দুটোই সব event পায়। এটা pub/sub এর মতো আচরণ।

একটা মজার সীমাও আছে। Partition তিনটা হলে group এ চতুর্থ consumer যোগ করে লাভ নেই। সে কোনো partition পাবে না, অলস বসে থাকবে। তাই topic বানানোর সময়েই ভেবে নিতে হয়, ভবিষ্যতে সর্বোচ্চ কতজন consumer একসাথে লাগতে পারে।

Kafka এর delivery নিয়েও সেশন ০৮ এর কথাটা খাটে। Consumer event process করে তারপর offset সেভ করে। মাঝখানে crash করলে একই event আবার আসে। তাই Kafka এর consumer কেও idempotent হতে হয়: একই OrderPlaced দুইবার এলে loyalty point যেন দুইবার যোগ না হয়।

০৫ একই order এর event গুলো ঠিক ক্রমে পৌঁছাবে তো?

এক সন্ধ্যায় একটা অদ্ভুত অভিযোগ এলো। একজন customer ৭:৪০:০১ এ order দিয়ে আট সেকেন্ড পরেই cancel করেছেন। তবু একজন rider রেস্টুরেন্টে গিয়ে হাজির। খাবার নেই, customer নেই, rider এর কুড়ি মিনিট নষ্ট।

রুবেল খুঁজে দেখলো, event দুটো দুই আলাদা partition এ গিয়েছিলো:

Kafka একটা কথাই নিশ্চিত করে: একটা partition এর ভেতরে event গুলো লেখার ক্রমেই পড়া হয়। কিন্তু দুই partition এর মধ্যে কোনো ক্রমের নিশ্চয়তা নেই। Partition 0 এ ৩০০টা event জমে থাকলে সেখানকার event দেরিতে পড়া হবে। Partition 1 খালি থাকলে সেখানকার event আগে পড়া হবে।

সমাধানটা সহজ। Event publish করার সময় একটা key দিতে হয়। Kafka key টাকে hash করে (একটা সংখ্যায় বদলে), partition এর সংখ্যা দিয়ে ভাগ করে, আর ভাগশেষ দেখে partition বেছে নেয়। সেশন ০৫ এ shard key দিয়ে ঠিক এভাবেই data ভাগ করেছিলেন। একই key সবসময় একই partition এ যায়। তাই order_id কে key বানালে order #5821 এর সব event একই partition এ, একই ক্রমে থাকে।

খেয়াল করুন, আমরা সব order এর মধ্যে ক্রম চাইনি। #5821 আর #5822 কোনটা আগে process হলো, তাতে কিছু যায় আসে না। আমাদের দরকার শুধু একই order এর ভেতরের ক্রম। এই ধারণার নাম ordering per key।

০৬ কেউ নির্দেশ না দিলে পুরো delivery flow চলে কীভাবে?

একটা order এ শুধু OrderPlaced হয় না। Restaurant order টা accept করে। তারপর rider খোঁজা হয়। Rider পেলে customer কে জানানো হয়। এই ধাপগুলো একটার পর একটা হতে হবে।

পুরোনো design এ order service সবাইকে নির্দেশ দিতো, একজন conductor এর মতো। নতুন design এ কেউ কাউকে নির্দেশ দেয় না। প্রতিটা service শুধু নিজের পছন্দের event শোনে, নিজের কাজ করে, আর কাজ শেষে নিজের একটা নতুন event ছাড়ে:

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

এর উল্টো পদ্ধতি হলো orchestration, যেখানে একটা কেন্দ্রীয় service প্রত্যেককে ধাপে ধাপে command পাঠায়। দুটোর তুলনা:

Choreography এর সবচেয়ে বড় downside হলো, পুরো ছবিটা কারো হাতে থাকে না। রুবেলের team এ একবার এমন হয়েছিলো: rider assign হচ্ছে না, কিন্তু কোন service এর কোন event আটকে আছে, তা খুঁজতে দুই ঘণ্টা লেগেছে। তাই প্রতিটা event এ order_id রাখুন, যাতে একটা order এর পুরো যাত্রা পরে খুঁজে বের করা যায়।

আরেকটা প্রশ্ন থেকে যায়: মাঝপথে কোনো ধাপ fail করলে কী হবে? যেমন, restaurant accept করলো, কিন্তু কোনো rider পাওয়া গেলো না। তখন আগের ধাপগুলো উল্টাতে হয়। এর জন্য saga নামের একটা আলাদা কৌশল আছে, যেটা আমরা সেশন ১৭ তে বিস্তারিত দেখবো।

০৭ Event এর format বদলালে কী হয়?

Schema evolution: পুরোনো পাঠককে না ভাঙিয়ে বদলানো

ছয় মাস পরে finance team চাইলো, OrderPlaced event এ payment method ও থাকুক (bKash, card, নাকি cash)। Event এর ভেতরে কোন কোন field থাকবে আর সেগুলো কোন ধরনের, এই কাঠামোকে বলে schema। আর সময়ের সাথে schema নিরাপদে বদলানোর কাজকে বলে schema evolution।

সমস্যাটা এখানে। Event এর publisher একজন, কিন্তু পাঠক ছয়জন। ছয়টা team একই দিনে deploy করবে, এটা আশা করা যায় না। তাই নতুন event পুরোনো পাঠকের কাছেও পড়ার মতো থাকতে হয়, আর পুরোনো event নতুন পাঠকের কাছেও। মনে রাখবেন, Kafka তে সাত দিনের পুরোনো event ও replay হতে পারে।

// v1: শুরুর event
{ "type": "OrderPlaced", "version": 1,
  "order_id": 5821, "total": 450 }

// v2: নতুন field যোগ করা (নিরাপদ)
// পুরোনো consumer অচেনা field টা এড়িয়ে যায়।
// নতুন consumer field না পেলে default ধরে: "cash"
{ "type": "OrderPlaced", "version": 2,
  "order_id": 5821, "total": 450,
  "payment_method": "bkash" }

// ভুল পথ: field এর নাম বদলানো
// পুরোনো consumer "order_id" খোঁজে, পায় না, crash করে।
{ "type": "OrderPlaced", "version": 3,
  "orderId": 5821, "amount": 450 }

নিরাপদ আর বিপজ্জনক বদলের তালিকা ছোট:

• নিরাপদ: নতুন field যোগ করা, যদি তার একটা default মান থাকে। পুরোনো consumer অচেনা field এড়িয়ে যায়।
• বিপজ্জনক: কোনো field মুছে ফেলা, নাম বদলানো, বা ধরন বদলানো (সংখ্যা থেকে text)। পুরোনো consumer যে field খোঁজে, সেটা আর পায় না।

বড় team গুলো এজন্য schema registry ব্যবহার করে। এটা একটা আলাদা service, যেখানে প্রতিটা event এর schema জমা থাকে। কেউ বিপজ্জনক বদল publish করতে চাইলে registry সেটা আটকে দেয়।

Event-carried state: event এ কতটুকু তথ্য রাখবেন

প্রথম দিকে রুবেলের event এ শুধু order_id থাকতো। SMS service কে customer এর phone number জানতে order service কে আবার call করতে হতো। Restaurant service কে খাবারের তালিকা জানতে আবার call। এই ছোট event কে বলে thin event।

হিসাবটা দেখুন। প্রতি সেকেন্ডে ৫০টা event, আর পাঁচটা consumer প্রত্যেকে একবার করে ফিরতি call করে। ফলে order service এর উপর প্রতি সেকেন্ডে ২৫০টা বাড়তি request আসে। তার চেয়েও খারাপ কথা, order service down হলে সবাই আবার আটকে যায়। যে coupling থেকে মুক্তি পেতে event এনেছিলাম, সেটা পেছনের দরজা দিয়ে ফিরে এসেছে।

সমাধান হলো দরকারি তথ্যটা event এর ভেতরেই পাঠানো: phone, address, খাবারের তালিকা, মোট দাম। একে বলে event-carried state transfer। Consumer কে আর কাউকে জিজ্ঞেস করতে হয় না। দরকারি data সে নিজের database এ রেখে দেয়।

এরও দাম আছে। Event বড় হয় (1 KB থেকে 2 KB)। একই data অনেক জায়গায় কপি থাকে। আর customer এর phone number এর মতো ব্যক্তিগত তথ্য অনেক service এ ছড়িয়ে পড়ে, যেটা নিরাপত্তার দিক থেকে ঝুঁকি। তাই প্রতিটা field এর জন্য প্রশ্ন করুন: কোনো consumer কি সত্যিই এটা চায়?

০৮ শুধু event জমিয়ে রাখলে কেমন হয়?

এখন পর্যন্ত রুবেলের database এ প্রতিটা order এর বর্তমান অবস্থাটা লেখা থাকে: “order #5821, মোট 460 টাকা”। Event গুলো শুধু খবর পৌঁছানোর কাজ করে।

একটা ভিন্ন পথ আছে। বর্তমান অবস্থা না লিখে শুধু ঘটনাগুলো লিখে রাখা। আপনার পাড়ার মুদি দোকানের বাকির খাতার কথা ভাবুন। দোকানদার খাতায় “রহিম সাহেবের মোট বাকি ৮৫০ টাকা” লিখে রাখেন না। লেখেন: “৩ তারিখ চাল ৫০০”, “৭ তারিখ তেল ৪৫০”, “১০ তারিখ জমা ১০০”। মোট কত, সেটা লাইনগুলো যোগ করে বের করেন।

এই পদ্ধতির নাম event sourcing। এখানে event গুলোই আসল data। বর্তমান অবস্থা আলাদা করে জমা থাকে না, প্রয়োজনে event গুলো replay করে বের করা হয়।

এর লাভ হলো, কখনো কোনো তথ্য হারায় না। Customer যদি বলেন “আমার কাছ থেকে বেশি টাকা কেটেছে”, খাতা খুলে দেখা যায় কোন মুহূর্তে কী হয়েছিলো। ব্যাংকের লেনদেনের হিসাব এভাবেই রাখা হয়।

কিন্তু খরচও কম না। একটা পুরোনো account এ দশ হাজার event থাকলে প্রতিবার সব যোগ করা ধীর। তাই মাঝে মাঝে একটা snapshot (ঐ মুহূর্তের মোট হিসাব) রেখে দিতে হয়। পুরোনো event কখনো মোছা যায় না, তাই তাদের schema ও চিরকাল সামলাতে হয়। আর “আজকের সব বাতিল order দেখাও” এর মতো সাধারণ query ও সরাসরি চালানো যায় না।

০৯ কখন event ব্যবহার করবেন না?

Event এর সুবিধা দেখে রুবেলের team এর এক junior সব কিছুতে event বসাতে চাইলো, এমনকি restaurant খোলা আছে কিনা সেই প্রশ্নেও। রুবেল তাকে থামালো। Event এর সবচেয়ে বড় বৈশিষ্ট্য হলো, publisher উত্তরের জন্য অপেক্ষা করে না। যেখানে উত্তর ছাড়া এগোনো যায় না, সেখানে event ভুল জিনিস।

আরেকটা কথা মনে রাখুন। Event এর পথে সব কাজ একটু দেরিতে হয়। Order হওয়ার পর loyalty point যোগ হতে হয়তো দুই সেকেন্ড লাগে। এই সময়ে customer app খুললে পুরোনো point দেখবেন। একে বলে eventual consistency: সব জায়গা শেষমেশ একই অবস্থায় পৌঁছায়, তবে সাথে সাথে নয়। সেশন ০৩ এ replication lag এর সময় এটা প্রথম দেখেছিলেন। Event ব্যবহার করলে এই দেরিটা মেনে নিতে হয়, আর UI তে “point যোগ হচ্ছে” এর মতো বার্তা দেখাতে হয়।

১০ মগজে প্রেশার দিন

আগে নিজে ভাবুন। তারপর উত্তর খুলে দেখুন: বেশিরভাগ মানুষ কীভাবে ভাবে, সেই চিন্তায় কী বাদ পড়ে, আর আসল কথাটা কোথায়।

১১ যে টার্মগুলো শিখলাম

১২ শর্ট সামারি

১৩ মনে রাখুন

• Event অতীত কালে কথা বলে, command ভবিষ্যৎ কালে। নাম অতীত কালে লিখতে না পারলে সেটা event নয়।
• একজন কাজ করবে হলে queue, অনেকে জানবে হলে pub/sub। একই message এ দুই রকম চাহিদা থাকলে Kafka এর consumer group দুটোই দেয়।
• Kafka পড়ার পরও event রাখে। তাই নতুন service পুরোনো ইতিহাস replay করে শুরু করতে পারে, আর bug ঠিক করার পর আবার হিসাব করা যায়।
• ক্রম শুধু একটা partition এর ভেতরে। যে জিনিসের ভেতরে ক্রম দরকার, সেটাকেই key বানান।
• Choreography তে প্রতিটা event এ একটা ID রাখুন। নাহলে একটা আটকে যাওয়া order এর যাত্রা খুঁজে পাবেন না।
• Schema হলো চুক্তি। Default সহ নতুন field যোগ করুন, কিন্তু পুরোনো field মুছবেন না বা নাম বদলাবেন না।
• এখনই উত্তর দরকার হলে event নয়। Payment approve বা stock check এর মতো প্রশ্নে সরাসরি call করুন।