Event driven architecture

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

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

ইভেন্ট ড্রিভেন আর্কিটেকচার এ ইভেন্ট হচ্ছে 

- Fact, Action, State Change

- Aways Immutable

- Can be store indefinitely 

- Can be consume multiple time by different services

ইভেন্ট ড্রিভেন আর্কিটেকচার এ তিনটা পার্টিসিপেন্ট থাকে 

প্রোডিউসার 

সে ইভেন্ট প্রোডিউস করে সেই প্রোডিউসার 

মেসেজ ব্রোকার 

যে ইভেন্ট স্টোর এবং  রাউট করে অনেক কনজুমার এর কাছে 

কনজুমার 

যে ইভেন্ট রিসিভ এবং প্রসেস করে 

রিকোয়েস্ট রিসপন্স মডেল ও ইভেন্ট ড্রিভেন মডেল 

যদিও দুটা মডেল এর মূল কাজ একই, কিন্তু তাদের কাজের ধরনের পার্থক্য আছে

- API কল বা রিকোয়েস্ট রিসপন্স মডেল হচ্ছে সিনক্রোনাস অন্যদিকে ইভেন্ট ড্রিভেন হচ্ছে এসিনক্রোনাস

- রিকোয়েস্ট রিসপন্স মডেল এ  ক্লায়েন্ট জানে কে সার্ভার কিন্তু ইভেন্ট ড্রিভেন এ প্রোডিউসার জানে না কে বা  কারা কনজুমার 

- রিকোয়েস্ট রিসপন্স মডেল হচ্ছে টাইট কাপল অন্যদিকে ইভেন্ট ড্রিভেন হচ্ছে লুজ কাপল