Spring Boot Interview Question - Reducing Cyclomatic Complexity in a Production API

Discussing Cyclomatic Complexity, Concepts and Code Examples.

Scenario

You’re working on a Stripe-like payments platform built with Spring Boot.

The processPayment() method started simple, but over 2 years:

• compliance rules were added

• fraud checks were bolted on

• region-specific logic crept in

• limits were added by product teams

Now SonarQube blocks merges because the method’s cyclomatic complexity exploded.

Here’s the current production code:

What is cyclomatic complexity — in real engineering terms?

Cyclomatic complexity is a measure of how many different execution paths exist in a piece of code.

But in production engineering, what it really represents is: How hard the code is to reason about, test, and safely change.

Each if, else, switch, loop, or conditional adds another possible path.

More paths mean:

• more edge cases

• more regression risk

• more test combinations

• more mental load for the next engineer

So cyclomatic complexity is less about math and more about:
- Number of branches: Number of behaviors to understand
- Number of paths: Number of ways the code can break
- Complexity score: Maintenance cost indicator

---

📢 Get actionable Java/Spring Boot insights every week — from practical code tips to real-world use-case based interview questions.

Join 5700+ subscribers and level up your Spring & backend skills with hand-crafted content — no fluff.

First 100 paid subscribers will get the annual membership at $50/year ( 67 already converted to paid, 33 remaining )

So far we have covered 48+ real world based interview questions and will add up to 100 by end of this year.

Not convinced? Check out the details of the past work

---

How would you refactor this without changing behavior?

Key fact is we should separate decision logic from orchestration. Currently one method does validation, compliance, fraud checks, and execution.

We should refactor by extracting rules while preserving order and outcomes.

Step 1 — Identify responsibilities hidden in the method

The original method mixes four concerns:

1. Request validation

2. Regulatory/business rules

3. Fraud checks

4. Payment execution

These should not live in one function.