Kepiye carane mbangun microservice nganggo Spring Boot: config, discovery, resilience?

Question

IT Interview Practice · Accepted Answer

Spring Boot ditambah Spring Cloud menehi kowe blok bangunan kanggo microservice. Telung masalah sing kudu dirampungake saben sistem terdistribusi yaiku **konfigurasi terpusat**, **service discovery**, lan **resilience** marang kegagalan parsial. ## Bagean-bagean sing obah ```text ┌── Config Server (git-backed properties) │ Client ──▶ API Gateway ──▶ Service A ──▶ Service B │ │ │ └──▶ Discovery (Eureka / K8s DNS) ◀── register + look up ``` - **Config Server** nyediakake properti saben layanan saka repo git terpusat, mula kowe ngganti config tanpa deploy maneh. Layanan narik iku nalika wiwitan (lan nyegerake liwat `/actuator/refresh`). - **Service discovery** (Eureka, Consul, utawa Kubernetes DNS) ngidini Service A nemokake Service B miturut *jeneng* tinimbang host sing di-hard-code, mula instansi bisa diskalakan lan pindhah kanthi bebas. - **API Gateway** (Spring Cloud Gateway) iku titik mlebu tunggal kanggo routing, auth, lan rate limiting. ## Resilience — bagean sing dilewati junior Ing sistem terdistribusi saben panggilan jaringan *bakal* gagal wektu wektu. Gunakake Resilience4j kanggo mandhegake siji layanan alon supaya ora nyebar dadi pemadhaman: ```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** kabuka sawise kegagalan bola-bali, mula panggilan gagal cepet tinimbang numpuk thread sing ngenteni dependensi sing mati. ## Kenapa iki penting Wawancara senior nyelidiki kadewasan sistem terdistribusi. Nyebut discovery lan config iku standar; sing mbedakake yaiku ngomong babagan **kegagalan**: circuit breaker, timeout, idempotensi, lan observabilitas (distributed tracing nganggo Micrometer/Zipkin). Kandidat sing kuat uga mbantah — nyathet yen microservice nambah biaya operasional lan monolith kerep dadi pilihan sing bener nganti skala nuntut liya.

Bagean-bagean sing obah

Resilience — bagean sing dilewati junior

Kenapa iki penting

Pitakon sing gegandhengan