Microservice Architecture Explained Simply: Service Communication, Data Replication, and Real-World Challenges

আপনারা অনেকেই Microservice Architecture সম্পর্কে শুনেছেন। কিন্তু অনেকেই আছেন যারা Microservice Architecture নিয়ে কিছুটা confused। আসলে এটি কী, কীভাবে কাজ করে এবং এটি Traditional Monolithic Application থেকে কীভাবে আলাদা?

চলুন আজকে খুব সংক্ষেপে Microservice Architecture সম্পর্কে একটি basic ধারণা নেওয়ার চেষ্টা করি।

আরেকটি গুরুত্বপূর্ণ বিষয় হলো, Microservice Architecture-এর অন্যতম বড় challenge হচ্ছে services-এর মধ্যে communication এবং data management। আজকে আমরা সেটাও basic level-এ বোঝার চেষ্টা করব।

চলুন আগে জেনে নেই Microservice কী এবং এটি Traditional Monolithic Architecture থেকে কীভাবে আলাদা।

Monolithic Architecture (Traditional Application)

Traditional Application-এ application's সব feature-এর code সাধারণত একটি single codebase-এর মধ্যে থাকে এবং একটি single database ব্যবহার করা হয়।

ধরুন আপনি একটি Online Store তৈরি করবেন। সেখানে থাকতে পারে:

• User Management
• Product Management
• Order Management
• Payment Management

সাধারণত আপনি একটি project setup করবেন, হতে পারে Node.js, Express, FastAPI বা অন্য কোনো framework দিয়ে। তারপর Login, Registration, Product Management, Order Management, Payment Processing, সব feature একই application-এর মধ্যে থাকবে এবং একই database ব্যবহার করবে।

আমরা প্রতিদিন যেসব application তৈরি করি, তার অনেকগুলোই আসলে Traditional Monolithic Application।

এবার চলুন Microservice Architecture সম্পর্কে জানি।

Microservice Architecture

Microservice Architecture-এ প্রতিটি feature-কে আলাদা independent service হিসেবে ভাগ করা হয়। অর্থাৎ প্রতিটি service-এর জন্য আলাদা codebase এবং আলাদা project থাকে।ধরুন আপনার application-এ নিচের feature গুলো রয়েছে:

• User Service
• Product Service
• Order Service
• Payment Service

এখানে প্রতিটি service-এর জন্য নিজস্ব codebase এবং নিজস্ব database থাকে। অর্থাৎ services গুলো সম্পূর্ণভাবে separated এবং independently deployable। এমনকি প্রতিটি service আলাদা programming language দিয়েও তৈরি করা যেতে পারে।

উদাহরণস্বরূপ:

• User Service → Node.js + Express
• Product Service → FastAPI
• Payment Service → Go
• Notification Service → Java Spring Boot

Microservice-এর মূল ধারণাই হলো Independence। অর্থাৎ যদি User Service down হয়ে যায়, তাহলে ideally পুরো system down হওয়া উচিত নয়। অন্যান্য services যতটা সম্ভব স্বাভাবিকভাবে চলতে থাকবে।

এখন প্রশ্ন আসে, যদি প্রতিটি service independent হয়, তাহলে তারা একে অপরের সাথে communicate করে কীভাবে?

ধরুন আমরা /orders endpoint-এ request পাঠালাম।

Order Service-এর প্রয়োজন হতে পারে:

• User Information
• Product Information
• Payment Information

কিন্তু এই data গুলো অন্য services-এর database-এ রয়েছে।

তাহলে Order Service এই data পাবে কীভাবে? এখানেই Microservice Architecture-এর অন্যতম বড় challenge শুরু হয়,

Service Communication

সাধারণত services-এর মধ্যে communication করার দুটি জনপ্রিয় পদ্ধতি রয়েছে:

1. Synchronous Communication

2. Asynchronous Communication

3. Synchronous Communication

এটি বোঝার জন্য সবচেয়ে সহজ approach। একটি service সরাসরি অন্য service-এর API call করে। উদাহরণ:

Payment Service → API Request → Order Service

যখন Payment Service-এর order সম্পর্কিত data দরকার হয়, তখন এটি Order Service-কে request পাঠায়। কিন্তু এখানে একটি সমস্যা আছে।

Microservice Architecture-এর মূল লক্ষ্য হচ্ছে প্রতিটি service-কে যতটা সম্ভব independent রাখা। কিন্তু এই approach-এ যদি Order Service down থাকে, তাহলে Payment Service-ও fail করতে পারে, কারণ API request সফল হবে না। অর্থাৎ Payment Service তার কাজ সম্পন্ন করার জন্য Order Service-এর উপর নির্ভরশীল।

যেখানে Microservice-এর মূল লক্ষ্যই হচ্ছে services গুলোকে যতটা সম্ভব independently কাজ করার সুযোগ দেওয়া।

আর services-এর সংখ্যা বাড়ার সাথে সাথে এই dependency গুলো manage করাও কঠিন হয়ে যায়।

তাহলে এবার চলুন দ্বিতীয় approach দেখি।

2.Asynchronous Communication

এই approach-এ services সরাসরি API call না করে Events-এর মাধ্যমে communicate করে। এখানে সাধারণত Kafka, RabbitMQ ইত্যাদি Message Broker ব্যবহার করা হয়। ধরুন একজন customer নতুন order তৈরি করলো।

Order Service একটি event publish করলো:

📢 OrderCreated

Payment Service এই event listen করে payment processing শুরু করলো।

Payment সম্পন্ন হওয়ার পর Payment Service আরেকটি event publish করলো:

📢 PaymentCompleted

এরপর Order Service event টি receive করে order status update করলো। এই approach-এর বড় সুবিধা হলো services-গুলোকে সব সময় direct API communication করতে হয় না।

তবে এখানেও আরেকটি challenge আসে।

ধরুন Order Service-এর প্রয়োজন:

• User Information
• Product Information

তাহলে Order Service-কে কোনো না কোনোভাবে User Service এবং Product Service থেকে data নিতে হবে। সেক্ষেত্রে বারবার Order Service-কে event raise করতে হবে বা request করতে হবে data পাওয়ার জন্য। কিন্তু এখানে আবার একই dependency problem তৈরি হচ্ছে। যদি User Service down হয়ে যায়, তাহলে Order Service প্রয়োজনীয় user data পাবে না। একইভাবে Product Service down থাকলে product data পাওয়া যাবে না।

কারণ Order Service-এর নিজের কাছে User Service বা Product Service-এর data নেই। তাই data পাওয়ার জন্য তাকে অন্য service-এর উপর নির্ভর করতেই হচ্ছে।

অর্থাৎ দ্বিতীয় approach-এ direct API dependency না থাকলেও data dependency এখনো রয়ে যাচ্ছে। আর Microservice-এর মূল লক্ষ্যই হলো প্রতিটি service যতটা সম্ভব independently কাজ করতে পারা।

তাহলে সমাধান কী?

Data Replication + Event-Driven Communication

Microservice System-এ বহুল ব্যবহৃত একটি pattern হলো Local Data Replication। এর অর্থ হলো Order Service তার নিজের order data তো store করবেই, পাশাপাশি Order Service-এর business logic-এর জন্য অন্য service-এর যেসব data দরকার সেগুলোর একটি local copy নিজের database-এ replicate করে রাখবে।

অর্থাৎ Order Service, User Service এবং Product Service-এর কিছু data duplicate করে নিজের database-এ রাখবে। ভবিষ্যতে যদি অন্য কোনো service-এর data প্রয়োজন হয়, তাহলে সেই service-এর দরকারি data-ও replicate করে রাখতে পারে।

তবে এখানে একটি খুব গুরুত্বপূর্ণ বিষয় আছে।

একটি service কখনোই অন্য service-এর সম্পূর্ণ database copy করে না। বরং শুধুমাত্র business logic-এর জন্য যেসব field প্রয়োজন, শুধুমাত্র সেগুলোই locally store করে।

চলুন একটি example দেখি।

ধরুন Order Service-এর একটি endpoint আছে:

/orders

যেখানে order-এর সাথে user information এবং product information-ও দেখাতে হবে। এই ক্ষেত্রে Order Service, User Service এবং Product Service-এর প্রয়োজনীয় data locally replicate করে রাখবে।

ফলে /orders endpoint serve করার সময় Order Service-কে আর User Service বা Product Service-এর উপর depend করতে হবে না।

Order Service সম্পূর্ণ independently request serve করতে পারবে।

তবে replication process-টা একটু ভিন্ন। Order Service শুধুমাত্র তার business logic-এর জন্য প্রয়োজনীয় data-ই store করবে।

ধরুন Main User Service-এর database structure:

• id
• name
• email
• password
• role

এখন প্রশ্ন হলো, Order Service-এর কি user-এর password দরকার?

অবশ্যই না। তাহলে Order Service শুধুমাত্র দরকারি field গুলো replicate করবে।

যেমন:

• userId
• userName
• email

একইভাবে Product Service থেকে:

• productId
• productName
• currentPrice

খেয়াল করুন

Order Service পুরো User বা Product database copy করছে না।

শুধুমাত্র order processing-এর জন্য প্রয়োজনীয় data রাখছে।

এখন প্রশ্ন হলো,

Order Service এই data পাবে কীভাবে?

ধরুন /orders/create endpoint-এ client request পাঠালো।

Request payload-এর মধ্যেই user এবং product সম্পর্কিত প্রয়োজনীয় information রয়েছে।

তখন Order Service:

• নতুন order create করবে
• প্রয়োজনীয় user data store করবে
• প্রয়োজনীয় product data store করবে

ফলে Order Service-এর কাছে সেই order-এর জন্য প্রয়োজনীয় local data copy তৈরি হয়ে যাবে।

এখন /orders endpoint সম্পূর্ণ independent।

যদি User Service বা Product Service down হয়ে যায়, তবুও Order Service request serve করতে পারবে। কারণ data পাওয়ার জন্য তাকে আর User Service বা Product Service-এর উপর নির্ভর করতে হচ্ছে না।

কিন্তু এখন প্রশ্ন হলো

যদি User Service থেকে user-এর নাম পরিবর্তন হয়?

অথবা Product Service থেকে product name update হয়?

তাহলে কী হবে?

এখানেই Events গুরুত্বপূর্ণ ভূমিকা পালন করে।

যখন User Service-এর data update হবে, তখন User Service publish করবে:

📢 UserUpdated

একইভাবে Product Service publish করবে:

📢 ProductUpdated

Order Service এই events listen করবে এবং প্রয়োজন অনুযায়ী তার local replicated data update করে নেবে।

অর্থাৎ User এবং Product data-এর local copy সব সময় reasonably up-to-date থাকবে। এখন Order Service অনেক বেশি independent।

• প্রতিবার অন্য service-কে call করতে হচ্ছে না

• Local data reasonably up-to-date থাকে

• Services আরও independent থাকে

• Network request কম হওয়ায় performance improve হয়

Data Replication এবং Event-Driven Communication-এর এই combination Microservice Architecture-এ খুবই common একটি pattern।

📌 Note:

এটি শুধুমাত্র Microservice Architecture-এর একটি basic overview।

বাস্তব production system-এ বিষয়টি আরও অনেক complex হয় এবং সেখানে Docker, Kubernetes, Pods, Clusters, API Gateway, Service Discovery, Load Balancer, Distributed Tracing, Circuit Breaker, Saga Pattern সহ আরও অনেক concept জড়িত থাকে।