Financial Services MSA Migration - Applying BFF and CircuitBreaker (Part 2)

In the Asset/Credit Management PT, BFF(Backend For Frontend) was introduced to combine and serve only the data needed by WEB and Mobile APP. Multiple APIs were bundled in one place to compose responses, the number of calls per service was reduced, and complex frontend logic and common processing (CORS, authentication, etc.) were consolidated into the BFF.

Unlike a typical API Gateway, BFF doesn't just forward frontend requests as-is; it actually transforms the response format to fit UI/UX needs. Through this structure, the FINDA APP main home combines and displays lending, deposit, and MYDATA information, and room was also left to add a WEB-dedicated BFF in the future.

Under high-traffic conditions, delays and errors in the MYDATA management service cascaded to other services, causing PODs to go Up & Down, and even slowing down overall app rendering. In particular, ahead of the loan refinancing (debt consolidation) launch, it was decided to introduce CircuitBreaker to prevent this kind of propagation.

The external communication layer was built on WebClient, and Resilience4J's CircuitBreaker was applied to block calls to failing services. @CircuitBreaker(name = "dms-api-service", fallbackMethod = "callApiMonoFallback") was attached to DmsWebClientApiComponent so that failures fall through to the fallback, and a FallbackMethodInvokedException was thrown to reflect it in the failure rate aggregation.

Configuration was separated per service, with the following default values.

• failureRateThreshold: 20
• slowCallRateThreshold: 20
• slowCallDurationThreshold: 60s
• permittedNumberOfCallsInHalfOpenState: 10
• slidingWindowType: COUNT_BASED
• slidingWindowSize: 100
• minimumNumberOfCalls: 10
• waitDurationInOpenState: 30s
• recordFailurePredicate: customized Predicate
• recordExceptions: HttpServerErrorException, TimeoutException
• ignoreExceptions: FindaHttpErrorException

The failure rate is calculated as number of failures / slidingWindowSize or minimumNumberOfCalls × 100, using the smaller denominator depending on the condition. For example, if 20 out of 100 calls fail, the failure rate is 20% and the CircuitBreaker transitions to the OPEN state.

After applying this, operational PODs no longer fluctuated unstably even when error rates rose, and the CircuitBreaker failure rate could be checked in Grafana while OPEN states could also be tracked via Slack alarms. As a result, unnecessary retries and Thread waste were reduced, effectively preventing external failures from spreading across the entire asset management service.