Spring Boot Interview Question — Your API Went Viral Overnight

One enthusiastic client can become your accidental DDoS 😄

Scenario

You own a Spring Boot backend powering merchant checkout APIs.

Core endpoint:

POST /api/payments/authorize

Traffic normally:

2,000 requests/minute

One day:

• a partner integration has a retry bug

• they start hammering your API

Traffic jumps: 2,000 req/min → 250,000 req/min

Symptoms:

• CPU spikes to 95%

• DB connection pool exhausted

• Redis overloaded

• payment gateway latency jumps

• healthy customers begin receiving 500s

PagerDuty:

Checkout API availability = 62%

Investigation finds:

80% traffic comes from 3 abusive API keys

Existing Code:

Controller:

---

📢 Get actionable Java and Spring Boot insights every week, including practical code tips and real-world, use-case-based interview questions, to help you level up your backend skills—join 7000+ subscribers for hand-crafted, no-fluff content.

First 100 paid subscribers will get the annual membership at $50/year forever that is ~ $4/mo ( 87 already converted to paid, 13 sport remaining)

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

Testimonials

---

What design changes would you make to the current Spring Boot system to protect availability during traffic spikes?

As we identified that the majority of the traffic comes from small subset of partners, we should first implement a rate limiting logic that prevents api to be hammered in short span by our partners.

1. We should reject traffic early (Edge / Gateway / Filter)

Protection should happen before controller/ service logic.

Client
 ↓
Gateway / Filter
 ↓
Controller
 ↓
Service
 ↓
DB / downstream

If rejected late:

• thread already allocated

• DB connection maybe allocated

• Redis call made

• downstream service touched

Too expensive. Hence we should reject early.

2. Identify who is consuming traffic

For every request, we can identify their identity and then apply rate limit.

POST /payments/authorize

We extract an identity: merchant_123 or api_key

Then rate limit: merchant_123 → 100 req/sec

Track requests per identity.