¿Cómo se construyen microservicios con Spring Boot: config, discovery, resiliencia?

Question

IT Interview Practice · Accepted Answer

Spring Boot junto con Spring Cloud te da los bloques de construcción para microservicios. Los tres problemas que todo sistema distribuido debe resolver son la **configuración centralizada**, el **service discovery** y la **resiliencia** ante fallos parciales. ## Las piezas móviles ```text ┌── Config Server (properties respaldadas por git) │ Client ──▶ API Gateway ──▶ Service A ──▶ Service B │ │ │ └──▶ Discovery (Eureka / K8s DNS) ◀── registra + busca ``` - **El Config Server** sirve las properties de cada servicio desde un repo git central, así cambias la config sin redesplegar. Los servicios la obtienen en el arranque (y refrescan vía `/actuator/refresh`). - **El service discovery** (Eureka, Consul o Kubernetes DNS) permite al Service A encontrar al Service B por *nombre* en lugar de un host hardcodeado, así las instancias pueden escalar y moverse libremente. - **El API Gateway** (Spring Cloud Gateway) es el punto de entrada único para routing, auth y rate limiting. ## Resiliencia — la parte que los juniors se saltan En un sistema distribuido toda llamada de red *fallará* tarde o temprano. Usa Resilience4j para evitar que un servicio lento provoque en cascada una caída total: ```java @CircuitBreaker(name = "inventory", fallbackMethod = "cachedStock") @Retry(name = "inventory") // reintenta fallos transitorios @TimeLimiter(name = "inventory") // limita la espera public CompletableFuture stock(String sku) { return inventoryClient.get(sku); // llamada remota } // Se llama cuando el circuito está abierto o la llamada falla — degrada con elegancia. public CompletableFuture cachedStock(String sku, Throwable ex) { return CompletableFuture.completedFuture(Stock.unknown(sku)); } ``` El **circuit breaker** se abre tras repetidos fallos, así las llamadas fallan rápido en lugar de acumular threads esperando a una dependencia muerta. ## Por qué es importante Las entrevistas senior indagan la madurez en sistemas distribuidos. Nombrar discovery y config es lo mínimo; el diferenciador es hablar de **fallo**: circuit breakers, timeouts, idempotencia y observabilidad (tracing distribuido con Micrometer/Zipkin). Los buenos candidatos también matizan: señalan que los microservicios añaden coste operativo y que un monolito suele ser la opción correcta hasta que la escala exija otra cosa.

Las piezas móviles

Resiliencia — la parte que los juniors se saltan

Por qué es importante

Preguntas relacionadas