Part 5 · 1 chapters · ~8 min

Spring Cloud and the Library Approach

Doing mesh-like work in-process: Spring Cloud Gateway, LoadBalancer, Config, Netflix Eureka, OpenFeign and Resilience4j, the equivalents in Go (go-kit, gRPC interceptors) and Node, and the trade-offs against sidecars.

Resilience and discovery in the application

code

// Spring Boot + Resilience4j: timeout, retry and circuit breaker around a call
@CircuitBreaker(name = "ledger", fallbackMethod = "pending")
@Retry(name = "ledger")
@TimeLimiter(name = "ledger")
public CompletableFuture<Balance> balance(String accountId) {
    return CompletableFuture.supplyAsync(() -> ledgerClient.balance(accountId));    // OpenFeign client, discovered via Eureka or k8s
}
private CompletableFuture<Balance> pending(String id, Throwable t) { return completedFuture(Balance.unavailable(id)); }

# application.yml
resilience4j.circuitbreaker.instances.ledger: { failureRateThreshold: 50, slidingWindowSize: 20, waitDurationInOpenState: 10s }
resilience4j.retry.instances.ledger: { maxAttempts: 2, waitDuration: 100ms, retryExceptions: [java.io.IOException] }

	library (Spring Cloud, Resilience4j)	sidecar mesh
knows business context	yes: fallbacks with domain meaning	no
polyglot consistency	no: one ecosystem	yes
upgrade	redeploy every service	roll the proxies
overhead	in-process, minimal	proxy hops and memory
mTLS	manual	automatic

Many companies use both: the mesh for mTLS, telemetry and coarse traffic policy; libraries for business-aware fallbacks and idempotent retries.