Spring Boot 3 and JVM Resilience in API Development: Avoiding JavaScript’s 2014 Pitfalls

Without proper thread pooling and structured error handling, your production APIs might face cascading failures under load—like Node.js applications did during JavaScript’s scalability debates in 2014—while Spring Boot’s thread-per-request model remains unmonitored and unoptimized.

Prerequisites

• Java 17 or later
• Spring Boot 3.2.4
• Spring Web and Spring Data JPA dependencies
• Docker 24.0+ and PostgreSQL 15 image
• Postman or curl for API testing

Configuring Spring Boot for Concurrent Request Handling

Spring Boot’s default Tomcat configuration handles 100 simultaneous requests, but tuning is critical for high-throughput APIs. Add these dependencies to optimize thread pools and metrics:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

server.tomcat.threads.max=200
server.tomcat.threads.min-spare=20
management.endpoints.web.exposure.include=health,metrics,threaddump

• server.tomcat.threads.max: Maximum worker threads for concurrent requests
• management.endpoints.web.exposure.include: Enables actuator metrics for monitoring thread usage

Implementing Resilient Order Processing with @RestController

This REST controller uses Spring’s thread-per-request model to avoid JavaScript-style event-loop blocking, with explicit error handling for database failures:

package com.example.orderservice;

import org.springframework.http.HttpStatus;
import org.springframework.web.bind.annotation.*;
import org.springframework.dao.DataAccessException;

@RestController
@RequestMapping("/orders")
public class OrderController {

    @PostMapping
    @ResponseStatus(HttpStatus.CREATED)
    public String createOrder(@RequestBody OrderRequest request) {
        try {
            // Simulate database operation
            processOrder(request);
            return "Order processed";
        } catch (DataAccessException e) {
            throw new ServiceUnavailableException("Database write failed");
        }
    }

    private void processOrder(OrderRequest request) {
        // Business logic here
    }
}

@ResponseStatus(HttpStatus.SERVICE_UNAVAILABLE)
class ServiceUnavailableException extends RuntimeException {
    ServiceUnavailableException(String message) {
        super(message);
    }
}

Test with curl -X POST http://localhost:8080/orders -H "Content-Type: application/json" -d '{"productId": 123}'. Verify thread usage via /actuator/metrics/tomcat.threads.busy.

Dockerizing PostgreSQL for Spring Data JPA

# docker-compose.yml
version: '3.8'
services:
  postgres:
    image: postgres:15-alpine
    environment:
      POSTGRES_DB: orders
      POSTGRES_USER: spring
      POSTGRES_PASSWORD: secure
    ports:
      - "5432:5432"

Run docker-compose up before starting the Spring Boot app to ensure database connectivity.

Common Mistakes

Mistake 1: Blocking the main thread with synchronous I/O

// Wrong: Synchronous HTTP call in controller
String result = restTemplate.getForObject("https://slow-api", String.class);

// Fix: Offload to @Async service
@Async
public CompletableFuture<String> fetchExternalData() {
    return CompletableFuture.completedFuture(restTemplate.getForObject(...));
}

Synchronous calls in controllers exhaust worker threads. Use @Async with a configured task executor.

Mistake 2: Missing retries for transient database errors

// Wrong: No retry for JPA operations
orderRepository.save(order);

// Fix: Spring Retry with exponential backoff
@Retryable(retryFor = DataAccessException.class, maxAttempts = 3)
public void saveOrder(Order order) {
    orderRepository.save(order);
}

Add @EnableRetry and spring-retry dependency to recover from transient database issues.

Mistake 3: Overlooking connection pool limits

# Wrong: Default Hikari pool size
spring.datasource.hikari.maximum-pool-size=10

# Fix: Match pool to thread capacity
spring.datasource.hikari.maximum-pool-size=200

Too few database connections cause thread starvation. Align Hikari pool size to Tomcat’s threads.max.

Summary

• Configure server.tomcat.threads.max to match expected concurrent users and monitor via /actuator/metrics
• Use @Async with a custom ThreadPoolTaskExecutor for I/O-bound operations to prevent thread blocking
• Set spring.datasource.hikari.maximum-pool-size equal to Tomcat threads to avoid database connection starvation

The author publishes Spring Boot starter templates at https://gumroad.com