Spring Boot দিয়ে আপনি কীভাবে microservice তৈরি করেন: config, discovery, resilience?

Question

IT Interview Practice · Accepted Answer

Spring Boot এবং Spring Cloud আপনাকে microservice-এর building block দেয়। প্রতিটি distributed system-কে যে তিনটি সমস্যা সমাধান করতেই হয় তা হলো **কেন্দ্রীভূত configuration**, **service discovery**, এবং আংশিক ব্যর্থতার বিরুদ্ধে **resilience**। ## চলমান অংশগুলো ```text ┌── Config Server (git-backed properties) │ Client ──▶ API Gateway ──▶ Service A ──▶ Service B │ │ │ └──▶ Discovery (Eureka / K8s DNS) ◀── register + look up ``` - **Config Server** প্রতিটি service-এর property একটি কেন্দ্রীয় git repo থেকে পরিবেশন করে, তাই আপনি redeploy ছাড়াই config বদলান। Service গুলো startup-এ তা টেনে নেয় (এবং `/actuator/refresh` দিয়ে refresh করে)। - **Service discovery** (Eureka, Consul, বা Kubernetes DNS) Service A-কে Service B-কে hard-coded host নয়, *নাম* দিয়ে খুঁজে পেতে দেয়, তাই instance গুলো অবাধে scale ও সরে যেতে পারে। - **API Gateway** (Spring Cloud Gateway) হলো routing, auth, এবং rate limiting-এর একক প্রবেশদ্বার। ## Resilience — যে অংশ junior-রা এড়িয়ে যায় একটি distributed system-এ প্রতিটি network call *একসময়* ব্যর্থ হবেই। একটি ধীর service একটি outage-এ পরিণত হওয়া থামাতে Resilience4j ব্যবহার করুন: ```java @CircuitBreaker(name = "inventory", fallbackMethod = "cachedStock") @Retry(name = "inventory") // retry transient blips @TimeLimiter(name = "inventory") // cap the wait public CompletableFuture stock(String sku) { return inventoryClient.get(sku); // remote call } // Called when the circuit is open or the call fails — degrade gracefully. public CompletableFuture cachedStock(String sku, Throwable ex) { return CompletableFuture.completedFuture(Stock.unknown(sku)); } ``` **circuit breaker** বারবার ব্যর্থতার পর খুলে যায় (trips open), তাই call গুলো একটি মৃত dependency-এর অপেক্ষায় thread জমা না করে দ্রুত ব্যর্থ হয়। ## এটি কেন গুরুত্বপূর্ণ Senior interview distributed-systems পরিপক্বতা যাচাই করে। discovery ও config নাম বলা ন্যূনতম শর্ত; পার্থক্যকারী হলো **ব্যর্থতা** নিয়ে কথা বলা: circuit breaker, timeout, idempotency, এবং observability (Micrometer/Zipkin দিয়ে distributed tracing)। শক্তিশালী প্রার্থীরা পাল্টা যুক্তিও দেন — উল্লেখ করেন যে microservice operational খরচ বাড়ায় এবং scale বাধ্য না করা পর্যন্ত প্রায়ই একটি monolith-ই সঠিক পছন্দ।

চলমান অংশগুলো

Resilience — যে অংশ junior-রা এড়িয়ে যায়

এটি কেন গুরুত্বপূর্ণ

সম্পর্কিত প্রশ্ন