Hoe bouw je microservices met Spring Boot: config, discovery, resilience?

Question

IT Interview Practice · Accepted Answer

Spring Boot plus Spring Cloud geeft je de bouwstenen voor microservices. De drie problemen die elk gedistribueerd systeem moet oplossen zijn **gecentraliseerde configuratie**, **service discovery** en **resilience** tegen gedeeltelijke uitval. ## De bewegende delen ```text ┌── Config Server (git-backed properties) │ Client ──▶ API Gateway ──▶ Service A ──▶ Service B │ │ │ └──▶ Discovery (Eureka / K8s DNS) ◀── register + look up ``` - **Config Server** serveert de properties van elke service uit een centrale git-repo, zodat je config wijzigt zonder te herdeployen. Services halen het op bij het opstarten (en verversen via `/actuator/refresh`). - **Service discovery** (Eureka, Consul of Kubernetes DNS) laat Service A Service B vinden op *naam* in plaats van een hard-coded host, zodat instances vrij kunnen schalen en verplaatsen. - **API Gateway** (Spring Cloud Gateway) is het enige ingangspunt voor routing, auth en rate limiting. ## Resilience — het deel dat juniors overslaan In een gedistribueerd systeem *zal* elke netwerk-call uiteindelijk falen. Gebruik Resilience4j om te voorkomen dat één trage service cascadeert tot een uitval: ```java @CircuitBreaker(name = "inventory", fallbackMethod = "cachedStock") @Retry(name = "inventory") // retry tijdelijke haperingen @TimeLimiter(name = "inventory") // begrens de wachttijd public CompletableFuture stock(String sku) { return inventoryClient.get(sku); // remote call } // Aangeroepen wanneer de circuit open is of de call faalt — degradeer netjes. public CompletableFuture cachedStock(String sku, Throwable ex) { return CompletableFuture.completedFuture(Stock.unknown(sku)); } ``` De **circuit breaker** springt open na herhaalde fouten, zodat calls snel falen in plaats van threads op te stapelen die op een dode dependency wachten. ## Waarom het belangrijk is Senior-interviews peilen volwassenheid in gedistribueerde systemen. Discovery en config noemen is basiskennis; de differentiator is praten over **falen**: circuit breakers, timeouts, idempotentie, en observability (distributed tracing met Micrometer/Zipkin). Sterke kandidaten duwen ook terug — door op te merken dat microservices operationele kosten toevoegen en een monoliet vaak de juiste keuze is totdat schaal iets anders vereist.

De bewegende delen

Resilience — het deel dat juniors overslaan

Waarom het belangrijk is

Gerelateerde vragen